On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:
> John Keeping <john@xxxxxxxxxxxxx> writes:
>
> > I've been annoyed by this at $DAYJOB recently. A lot of people seem to
> > blindly "git pull" without much thought about how the history is ending
> > up and what they actually want to do.
>
> I think these two are essentially the same thing, and having an
> option to flip the heads of a merge only solves a half of the
> problem.
>
> A merge that shows everybody else's work merged into your history
> means you are the integrator, the keeper of the main history. And
> the first-parent view of the history is useful only when the keeper
> of the main history takes good care of the main history.
>
> When you are using a "central shared repository" workflow, if you
> had and used an option to flip the heads of a merge to record what
> you have done so far as a side branch of what everybody else did to
> do the merge, or if you rebased your work on top of what everybody
> else did, the first-parent view would make a bit more sense than
> what you currently get. At least, everybody else's work will not
> appear as a side branch that does 47 unrelated things, and your work
> will appear as a side branch. That is a big plus.
>
> But the other half of the problem still remains, i.e. "what they
> actually want to do". People tend to do too many "pull" when their
> work is not ready, only to "catch up", and that is the real problem.
...
> One obvious way to solve it is to use a topic branch workflow (the
> first picture above; 'x's are built not on local 'master'), and you
> do a "git pull" from the shared repository while you are on your
> 'master', which is free of your 'x's until that 6-commit series is
> complete and ready. Then you locally merge that topic branch and
> push it back for everybody to see, which will give you the first
> picture in this message. Incidentally, this does not need the "flip
> the heads" option.
Yes, I don't think this is as much of a problem when using a topic
branch workflow, because it's clear what the history should look like
and users are expected to get it right.
Where I see this is when people are aiming for a linear history but
don't get that because with "git pull" to catch up they end up with
these backwards merges. In these cases, I think what users really want
is "git pull --rebase".
I have to wonder how often "git pull" with no arguments actually does
what users really want (even if they don't know it!) when it doesn't
result in a fast-forward (and pull.rebase isn't configured).
Hence my suggestion to error when "git pull" doesn't result in a
fast-forward and no branch name is specified. We could give some advice
like:
Your local changes are not included in the local branch and you
haven't told Git how to preserve them.
If you want to rebase your changes onto the modified upstream
branch, run:
git pull --rebase
> Solving half a problem is better than solving no problem, and
> especially because not all changes need to be multi-commit series
> but can be done directly, perfectly and fully on the local 'master'
> (i.e. 2+3+1=6 split would not happen for such changes). For these
> reasons, I personally am not strongly opposed to a "flip the heads"
> option, if implemented cleanly.
>
> But people need to realize that it is not solving the other half, a
> more fundamental problem some people have in their workflow.
Yes, but some users don't realise that their workflow is broken, and
perhaps we can nudge them in the right direction.
--
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