[Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?)

Welbourne Edward edward.welbourne at theqtcompany.com
Mon Apr 4 13:56:23 CEST 2016


René J.V. Bertin
> I've seen graphical utilities that attempt to show the branch
> hierarchy in some kind of tree,

You can even use: git log --graph
if you can cope with ASCII art ;-)

> but apparently miss from `git help branch` if it's possible to know
> the origin branch of a topic branch. Is it?

In some fundamental sense, git doesn't believe in a branch as anything
other than its current tip, with a directed graph of ancestor commits
stretching back from it.  It's important to understand that git doesn't
believe in any constraints on that directed graph other than being
acyclic (which causality suffices [0] to ensure, if all commits are done
with git tools).

Even when your revision graph is a strict tree, it can't tell which of
two branches was the "parent" and which the child; it only knows that
they have common histories past their last common ancestor - their
merge-base - if you have a strict tree, this isn't a merge, so it's
where one was branched off the other, but nothing about the merge-base
or any of its ancestors contains any hint as to which branch it was on
when it was committed.

When your history contains branching and merging - any acyclic directed
graph is permitted as a commit history - you can have two branches that
weave in and out of each other, thanks to cross-merging back and forth,
originating as branches off some entirely other branches that had done
the same, with some distant ancestor as merge-base.  If I give you the
graph of the resulting commit ancestry, with the current tips of some
branches labelled with their names, there's no way to tell which
branched off which other.  The branch names only exist at the tips.

[0] I imagine it would be possible, by hand-crafting, to build a cycle
in the object graph; but you'd need to ensure a consistent chain of
sha1s satisfying the necessary constraints.  I believe sha1 isn't broken
enough for us to yet know how to construct that (which amounts to trying
to concoct a new child commit with the same sha1 as one of its
ancestors, then removing the ancestor and substituting this child in its
place); if we did, I can imagine git getting quite upset if asked to
play with the result.

If I want to know what a branch is based on (and I carelessly didn't
include that in the name of the branch), I presume it's one of the usual
suspects (5.5, 5.6, 5.7, dev) and see which one has the closest ancestor
as git merge-base; or I pipe git shortlog 5.6...$branch | wc -l and
similar for each suspect base, to see which is shortest.  There's no way
to know what I branched off, but it's easy enough to work out which of a
given few branches is closest to a given tip.

	Eddy.



More information about the Development mailing list