Thanks. > On 22 Feb 2022, at 17:14, Justin <[email protected]> wrote: > > Personally, I try to make sure that regular-merges are the norm, and > rebase/reset is the exceptional case. Once you use rebase, you typically > need to use force-push, and once you start using force-push regularly, it is > easy to lose commits because you force push and actually lose something on > the remote that you didn't incorporate into the local push-source. > > If you never commit to your local master (or origin/master), it will never > diverge from upstream/master, and the reset/push --force will not be > necessary. > > I don't think you comments match what is being done: > > git checkout master # switch to local branch master > git pull upstream master # fetch upstream master and merge upstream/master > into current branch > # does not: overwrite my local master with remote upstream/master
Yes, the comment is wrong. After all I had just checked out master. But I have been advised a pull is not enough, I should first do a fetch. > git reset --hard upstream/master # move local branch to point to > upstream/master > git push origin master --force # push master branch back to fork's master > portindex > > These instructions would be (kind of) correct if you think the origin/master > branch or local master branch might diverge from upstream/master. Yes. Before I update my master with the upstream, I need to work with it as is. Or I need to update any branch I work on from the upstream master. In both cases I have too many things that change concurrently and things that go wrong are then impossible to catch. > However, even then, you have a pull (which merges), then a reset (which > discards). That is, either: > > git checkout master ; git pull upstream master ; git push > > or: > > git checkout master ; git fetch upstream ; git reset --hard upstream/master ; > git push --force origin master > > The reset/force-push is a bit contradictory: the instructions indicate that > something might have been added to the master branch, but it is being > discarded. Why would something be added to the master branch if it should > not be retained. It is just to be 100% certain that my master reflects upstream master > Also, why pull (merge) if the next step is going to reset --hard. If the > branches have diverged, you might have a merge conflict. > > The "git push --force" would close an open PR if the PR's branch was your > master branch (since origin/master and upstream/master are the same, the PR > would be closed). Otherwise, I don't see how pushing to master would affect > PRs on non-master branches. > > My approach: > > a) Never commit to your fork's master (besides pull from upstream) > b) Always push your changes to fork's branch(es) > c) PRs from fork branch That is what I do. But I cannot always have my own master be exactly like the upstream because of the ’too many changes and I’ll never find what causes it' > > A periodic "git checkout master && git pull upstream master && git push" > should keep fork's master branch up-to-date. Should there not be a fetch somewhere? > > As to whether you local git repo is ok: > > - Check "git status" does not show anything modified (or not checked in) > - Once you see everything is checked in, "git diff upstream/master" will show > diffs between local commit > - "git rev-parse HEAD upstream/master" will show the SHAs of you local branch > and upstream/master. It seems like you want them to be the same. > > -Justin > > On 2/19/22 07:59, Gerben Wierda via macports-users wrote: >> I have my own fork&clone of macports-ports in case I want to do maintenance. >> Getting a clean local clone for me means: >> >> # First, do an update of macports base only (does not update the ports tree): >> >> sudo port selfupdate --no-sync >> >> # Updating the master of my fork&clone from the master of the original: >> >> git checkout master # Go to branch master in my local clone >> git pull upstream master # Update my local clone master from the >> master of the remote upstream >> # (overwrites my local master with >> remote github/macports/master) >> git reset --hard upstream/master # Resets index and working tree of >> local clone/master from remote upstream >> git push origin master --force # Push local clone >> (~/MacPortsDev/macports-ports) master back >> # to my own remote fork >> (github/gctwnl/macports-ports) >> # NOTE: this closes all open >> pull-requests! >> portindex # Tell macports to use this tree and >> update the macports index >> >> Apparently, in the past UI have accidentally done some of this as root, so >> this failed because parts of the macports-ports clone were owned by root. >> >> So, I did a chown -R on that tree and tried again, but now I get >> >> albus:macports-ports sysbh$ git pull upstream master >> From https://github.com/macports/macports-ports >> <https://github.com/macports/macports-ports> >> * branch master -> FETCH_HEAD >> Updating e0a3df02c73..eca5c1226ee >> error: Your local changes to the following files would be overwritten by >> merge: >> >> _resources/port1.0/checks/implicit_function_declaration/macosx10.10.sdk.list >> >> _resources/port1.0/checks/implicit_function_declaration/macosx10.11.sdk.list >> … >> error: The following untracked working tree files would be overwritten by >> merge: >> aqua/qt5/files/patch-qtwebengine_gn_binary_path.diff >> comms/s710/files/dynamic_lookup-11.patch >> >> So I tried to do >> >> git reset --hard upstream/master >> >> and apparently this did work as another pull did nothing. But before I push >> that back to my own clone: have I done anything wrong? Is my local tree in >> order now? >> >> Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>) >> R&A IT Strategy <https://ea.rna.nl/> (main site) >> Book: Chess and the Art of Enterprise Architecture >> <https://ea.rna.nl/the-book/> >> Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/> >> >
