also sprach Junio C Hamano <gitster@xxxxxxxxx> [2009.02.12.2201 +0100]:
> It would be nice to hear TopGit people defend why setting HEAD to outside
> refs/heads/ is justified, why doing so should not break other things, and
> why it was needed.
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.
--
.''`. martin f. krafft <madduck@xxx> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
in the beginning was the word,
and the word was content-type: text/plain
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
