Re: [topgit] tg update error

also sprach Junio C Hamano <gitster@pobox.com> [2009.02.12.2201 +0100]:

As far as I understand it, TopGit does not /need/ to set HEAD to refs/top-bases/foo, but it currently does so as part of its algorithm:

When tg-update updates a depending branch, it first merges the dependent branch into the base of the topic branch, which is pointed to by the corresponding top-base (refs/top-bases/foo). It then merges the top-base into the topic branch, "foo" in this case.

The result is the same as if the base branch had been merged into "foo", and refs/top-bases/foo updated to point to the head of the base branch.

This stops working, however, as soon as you have a topic branch depending on more than one base branches. Since you need to track the base of a topic branch (e.g. in order to be able to get the diff represented by the TopGit branch), you now have a problem: which of the base branches is the base to diff against?

TopGit addresses this requirement by creating a "virtual" branch into which it merges all the bases (into the top-base) first, and then merging this "virtual" branch into the topic branch. The result is a merge commit combining all bases, which is a parent of the merge commit into the topic branch, and can thus serve as the origin of a diff calculation.

TopGit right now does all of this while HEAD is detached: it points into the refs/top-bases/* namespace -- the "virtual" branch. Here, it does the merges of the bases, and then checks out the topic branch to merge this combined ("virtual") base.

To work around the new restriction in Git, TopGit would need to make a proper branch, merge the bases into it, merge that branch into the topic branch, and the probably delete the branch pointer, as it's no longer needed and would only pollute the refs/heads/* namespace. It could certainly do this (with a minor performance impact), but it seems like jumping through hoops and around Git's restrictions, without any real benefit.

Point being: I understand the reason behind the restriction, and I wouldn't mind if it were default, but maybe there could be a controlled way to circumvent it for cases like the one described above, where it is safe to assume that the user^W^W the tool "knows" what it is doing.