Dmitry Potapov <dpotapov@xxxxxxxxx> writes:
> On Mon, Apr 20, 2009 at 03:52:59PM +0200, Michael J Gruber wrote:
> ...
>> A git branch is a pointer to a commit. That commit and its predecessors
>> are contained in the branch. A commit may be contained in multiple
>> branches, on equal footing: there is no "prime branch".
>
> This is not accurate description.
On the contrary, Michael's description is very accurate; its problem may
be that it is too accurate to be useful for people who do not use certain
features.
> The aforementioned pointer is called
> "branch head". Branch (in strictly sense) is a line of development,
> which is defined by its head. A usual commit has one parent; a merge
> commit can have more than one parent, the first parent defines the
> branch line while other parents point to branches merged to it.
Now, that again is technically accurate but is not very useful or even
harmful if you read too much into --first-parent.
Dscho may have been working on this nifty feature while my tree added tons
of changes that conflict with his work based on an older tree of mine.
And then he says "I have a clean history of this new feature; please pull".
o---o---o---o---o Dscho's changes
/
---o---D---D---D---o My tree
^
| D = changes from Dmitry that conflicts with Dscho's branch
v1.6.2
I may pull, and see a lot of conflicts; being unfamiliar with what he did,
I may say "I tried to pull, and I give up---there are too many conflicts
with what patches from Dmitry did recently since your tree forked, and I
do not know the area affected very well, so I feel uneasy doing the merge
myself."
o---o---o---o---o Dscho's changes
/ .
---o---D---D---D---o...X My tree, unable to resolve conflicts
^
| D = changes from Dmitry that conflicts with Dscho's branch
v1.6.2
Dscho can do two things. One is to rebase, but his code was in use
outside of my tree for some time and doing so will screw up other people.
But he can merge my tree and resolve the conflicts, and then tell me to
pull again.
Dscho's changes
o---o---o---o---o---M
/ /
---o---D---D---D---o---. My tree
^
| D = changes from Dmitry that conflicts with Dscho's branch
v1.6.2 M = merge made by Dscho for me
Now, if I did the merge, the first parent of X would have been the tip of
my tree that had patches from you, and it would have merged Dscho's
changes as a side branch. But if Dscho did a merge _for me_, then his
merge M will have his history as the first parent, and your patches
(together with possibly ones from other people) will be merged into the
history as a side branch.
However, especially after I fast-forward my branch tip to M and continue
building on it, it is more useful to treat Dscho's topic as the side
branch that was merged to my mainline that had your patches, for the
purpose of most people. Your "first parent" rule does not match that
expectation.
If we made it easy for Dscho to create the merge M to record my tree as
the first parent, you _could_ make the "first parent" rule to be more
meaningful than it currently is, but without it, it still is merely one of
the heuristics as people suggested in this discussion.
--
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