Re: What are branches?

Marius Vollmer [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

If we made it easy for Dscho to create the merge M to record my tree as
the first parent, [...]

But it _is_ easy for Dscho to do that, isn't it?  He just needs to
remember to do the merge the other way around, checking out your branch
and merging his into it.

This doesn't change much, of course, since we still can't follow a
branch backwards in time reliably.  Would it make sense to record
additional information in a merge commit, such as the branch name for
each parent?  Then tools could automatically draw the history of the
current branch as a straight line, say.

We already have record of that, but I do not think using it is necessarily
healthy.

There are certainly cases where the relationship between the maintainer
and a contributor makes one branch "the primary" in the sense that it is
the integration ground for everything under the sun, as opposed to the
other one that is "the side branch that was merged" in the sense that it
brought in a more narrowly focused set of patches.  If you examine the
merge commit M Dscho makes in the example in my previous message, it shows
that one of the parents was committed by me and the other was committed by
Dscho.  By following my commits over Dscho's, you will identify which one
of the parents of a merge is the mainline.  You would perhaps instead of
"git log --first-parent" use "git log --mainline=gitster" or something
like that.

The point is that a convention to follow my commits over Dscho's commits
is just as valid as a convention to follow the first parent.  It is purely
a social convention.

A more problematic is that in a distributed environment, there doesn't
necessarily such a "mainline vs side branch" relationship exist, and it is
not healthy to try to introduce such a concept like "mainline" when there
is no such thing.

Perhaps Alice and Bob forked at the same point, agreeing between
themselves that Alice works on the code updates while Bob updates the
documentation as a team of two to produce a new feature.  Before they
collectively conclude their work and send a pull request to the project
management, they will merge their branches to produce the end result that
is pullable.  From the overall project's point of view, the merge to get
their work into the mainline will be "the mainline merges one side branch
for the feature", but what about the merges between Alice and Bob while
they work together?  There is no "this is the mainline and this is a side
branch" relationship between what they do.