On 4/16/21 5:33 PM, Yves Guillemot wrote:
Thanks Ted,
Your operating manual is very clear.
Good to hear. Git's hard enough. A decent guide should make a big
difference.
I understand that the first simplified workflow was :
- Commit modifications on the local master
- Push them on the remote fork master and send a pull request
- Then the remote fork will be merged to the original master
- Now if I fetch changes from upstream, I'm going to get merge
conflicts because changes are already on the local master.
Maybe, but that's normal even in the branched situation.
The problem committing to master is that you will very likely end up
in a situation where your fork's master cannot be "fast-forwarded" and
instead git will need to play tricks and rewrite a little history to get
everything up there. The server will see this, enforce fast-forwarding
(no changes to history), and refuse to accept your push. This is
important because it can become something of a mess if someone is
following your branch. They have to realize you have done a forced push
and they can't just pull. They likely have to fetch and reset.
It's best to play by git's rules. The reality is that you *can* do a
non-fast-forward push and other folks following you can easily
accommodate. But usually it is frowned upon.
Let me know if you want me to try to work up an example. I have a
fork and I can make a royal mess of it and document what happens along
the way. Then I can straighten it out by moving the commits to master
over to a new branch and fixing local master. Fixing remote master
could end up being an interesting challenge, though, since I've pushed
my own version of master.
and the new better workflow is :
- Commit modifications on a local branch
- Push them on the same branch of the remote fork and send a pull
request
- Then the branch of the remote fork will be merged to the original
master
Simple up to this point.
- Now if I fetch changes from upstream, they are merged to the local
master without any conflict because the initial changes are on a
branch and not on this master.
Yes. Your local master will simply fast-forward to where
upstream/master is. (Again the issue isn't conflicts, it's
fast-forwarding vs. modifying history.)
And if you go ahead and rebase your local branch on master, all the
commits will disappear because they have already been accepted into
master. This is some of the magic of git that is really handy. (I
think svn does something similar but it's not as quick and flexible.)
Example:
Switch to local master branch.
git checkout master
Fetch the upstream/master branch and move your local master to it.
git pull --tags upstream
Switch over to your local branch.
git checkout yourbranch
And move it so that it starts at master:
git rebase master
If all commits were accepted to the upstream master, yourbranch will
now point to master.
- Then I can delete the branch which is now useless.
Exactly. I would do the rebase just to make sure the commits were
merged into upstream master, then the delete will succeed with a
lowercase "-d" since the branch is empty.
git branch -d yourbranch
Is this correct ?
You are definitely getting it. Keep going. The beauty of git is the
fact that you can just work and work and no one has to see any of it
until it is ready. No pressure to push *every single commit* to the
official repo. Or struggle with heavyweight remote branches. It's
liberating.
Ted.
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
