Richard Hansen wrote:
> I think the fundamental difference is in the relationship between the
> local and the remote branch (which branch derives from the other).
> The relationship between the branches determines what the user wants
> from 'git pull'.
> In my experience 'git pull' is mostly (only?) used for the following
> three tasks:
> 1. update a local branch to incorporate the latest upstream changes
> In this case, the local branch (master) is a derivative of the
> upstream branch (origin/master). The user wants all of the
> commits in the remote branch to be in the local branch. And the
> user would like the local changes, if any, to descend from the tip
> of the remote branch.
My current propsal of making `git pull` by default do --ff-only would
solve this. In addition I think by default 'master' should be merged to
'origin/master', if say --merge is given.
> For this case, 'git pull --ff-only' followed by 'git rebase -p'
> works well, as does 'git pull --rebase=preserve' if the user is
> comfortable rebasing without reviewing the incoming commits first.
I suppose you mean a `git rebase -p` if the `git pull --ff-only` failed.
This might be OK on most projects, but not all.
What happens after a `git pull --ff-only` fails should be totally
up to the user.
> 2. update a published feature branch with the latest changes from its
> parent branch
> In this case, the local branch (foo) is a derivative of the
> upstream branch (origin/foo) which is itself a derivative of
> another branch (origin/master). All commits in origin/master
> should be in origin/foo, and ideally all commits unique to
> origin/foo would descend from the tip of origin/master.
I don't understand why are you tainting the example with 'origin/foo',
'foo' and 'origin/master' are enough for this example. In fact, the
mention of 'origin/master' made it wrong: after the pull not all the
commits of origin/master would be in origin/foo, you need a push for
that. We have enough in our plate to taint this with yet another branch
For this case `git pull origin master` already work correctly for most
projects. We probably shouldn't change that.
> 3. integrate a more-or-less complete feature/fix back into the line
> of development it forked off of
> In this case the local branch is a primary line of development and
> the remote branch contains the derivative work. Think Linus
> pulling in contributions. Different situations will call for
> different ways to handle this case, but most will probably want
> some or all of:
> * rebase the remote commits onto local HEAD
No. Most people will merge the remote branch as it is. There's no reason
to rebase, specially if you are creating a merge commit.
> * merge into local HEAD so that the first parent (if a real merge
> and not a ff) is the previous version of the main line of
> development and the second parent is the derivative work
> * merge --no-ff so that:
> - the merge can serve as a cover letter (who reviewed it,
> which bug reports were fixed, where the changes came from,
> - the commits that compose the new topic are grouped together
> - the first-parent path represents a series of completed tasks
It is very rare that an integrator is even able to do a fast-forward
merge anyway. So being explicit about --no-ff might better, but it would
hardly make a difference. Either way, a good integrator would configure
pull.ff = false.
I'd say `git pull origin master` already works fine for this case.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html