Richard Hansen wrote:
> On 2014-05-03 05:26, Felipe Contreras wrote:
> > 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:
> >
> > I agree.
> >
> >> 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.
>
> It would go a long way toward improving the situation, yes.
>
> > In addition I think by default 'master' should be merged to
> > 'origin/master', if say --merge is given.
>
> This would break cases #2 and #3. (With cases #2 and #3 you want the
> fetched branch to be the second parent, not the first.)
>
> Or are you proposing that pull --merge should reverse the parents if and
> only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
> >
> >> 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.
>
> Yes.
>
> > This might be OK on most projects, but not all.
>
> The rebase only affects the local repository (the commits haven't been
> pushed yet or else they'd be in @{u} already), so I'd say it's more of
> an individual developer decision than a project decision.
>
> In my opinion rebase would be the best option here, but if the project
> is OK with developers pushing merge or merge-there commits and the
> developer isn't yet comfortable with rebasing, then merge is also an
> acceptable option.
Precisely for that reason.
> >> 2. update a published feature branch with the latest changes from its
> >> parent branch
> > We probably shouldn't change that.
>
> If we change 'git pull' to default to --ff-only but let 'git pull
> $remote [$refspec]' continue to default to --ff then we have two
> different behaviors depending on how 'git pull' is invoked. I'm worried
> that this would trip up users. I'm not convinced that having two
> different behaviors would be bad, but I'm not convinced that it would be
> good either.
It is the only solution that has been proposed.
Moreover, while it's a bit worrisome, it wouldn't create any actual
problems. Since `git pull $what` remains the same, there's no problems
there. The only change would be on `git pull`.
Since most users are not going to do `git pull $what` therefore it would
only be a small subset of users that would notice the discrepancy
between running with $what, or not. And the only discrepancy they could
notice is that when they run `git pull $what` they expect it to be
--ff-only, or when the run `git pull` they don't. Only the former could
be an issue, but even then, it's highly unlikely that `git pull $what`
would ever be a fast-forward.
So althought conceptually it doesn't look clean, in reality there
wouldn't be any problems.
> >> 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.
>
> I disagree. I prefer to rebase a topic branch before merging (no-ff) to
> the main line of development for a couple of reasons:
Well that is *your* preference. Most people would prefer to preserve the
history.
> * It makes commits easier to review.
The review in the vast majority of cases happens *before* the
integration.
And the problem comes when the integrator makes a mistake, which they
inevitable do (we all do), then there's no history about how the
conflict was resolved, and what whas the original patch.
That's why most people don't do this.
> * Rebasing makes the commit history pretty and easier to understand.
It is more important to be able to track integration errors than to have
a pretty history. That is for most people.
I like to have a pretty history for my own local branches, but once
something gets integrated it's important to see who did exactly what
(the integrator did the merge).
> > It is very rare that an integrator is even able to do a fast-forward
> > merge anyway.
>
> It depends on the level of project activity. A project as active as the
> Linux kernel or Git will almost never have fast-forwards. But
> occasional contributions by random users to a small, simple project will
> likely be fast-forwards.
And small simple projects don't care about such issues.
> > 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.
>
> Configuring pull.ff = false is OK if the integrator only integrates and
> only uses one machine. But if the integrator also wants to develop in
> the same repository, or if the integrator uses multiple machines to do
> the integration work (e.g., office desktop and laptop), then setting
> pull.ff may be less convenient, not more.
Any good integrator would find solutions for those problems easily.
Either way I don't see any proposed solutions.
> > I'd say `git pull origin master` already works fine for this case.
>
> It does, but again preserving the current behavior would cause the
> behavior of 'git pull origin master' to be inconsistent with the
> proposed ff-only default for a plain 'git pull'.
Yes, it doesn't look clean. But I don't see any proposed alternatives.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html