Re: first parent, commit graph layout, and pull merge direction
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:25
John Keeping [off-list ref] 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.
Instead of having a nice "these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully" history that explains how these commits were
related and these commits are the full solution to a single issue:
x---x---x---x---x---x
/ \
---o---o---o---o---o---o---M---o---o---...
they end up with something like this, even with the "flip the heads
of a merge" option, by pulling too often:
x---x x---x---x x
/ \ / \ / \
---o---o---M---o---o---M---M---o---o---...
The result fragments otherwise a logical and clean "single strand of
pearls to fully address the issue, consisting of 6 commits", into
separate and seemingly unrelated pieces.
Imagine that other people are working the same way, and the commits
marked with 'o' are merges of side branches they add their half-way
work to the main history similar to what happened in the second
illustration above. You would get this history:
x---x x---x---x x
/ \ / \ / \
---o---o---M---o---M---M---M---o---o---...
\ /
y---y
Nothing, other than the labels I used in the picture, ties these
'x's together while differentiating them from 'y's, so you lost an
important information. Unless people stop doing that too many
"pull"s that are used only to "catch up", even with the "flip the
heads of a merge" option, you will not get a history that yields a
good first-parent view.
That gets back to what I said in the second paragraph of this
message. When you "pull" from the central shared repository, with
the "flip the heads of a merge" option, you are acting as the keeper
of the main history at that point, and you are responsible for
taking good care of it. If you make a 2+3+1=6 mess as depicted in
the last illustration above, you are failing to do so.
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.
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.