Is this git handling of a problem on my macports-ports fork&clone OK?

Tue Feb 22 20:24:11 UTC 2022

Thanks.

> On 22 Feb 2022, at 17:14, Justin <justinvallon at gmail.com> 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/>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20220222/2d290c12/attachment.htm>