Junio C Hamano wrote:
>
> A branch in git, as Randal often used to say on #git, is an illusion---it
> points only at the top and does not identify the bottom.
>
> But it does _not_ have to stay that way at the Porcelain level.
>
> Here is a rough sketch of one possible solution. It is not fully thought
> out; the basic idea is probably sound but I did not try to exhaustively
> cover changes to various tools that are necessary to maintain the
> invariants this scheme requires.
>
> (0) Define a way to identify the bottom of a branch. One way to do this
> is by an extra ref (e.g. refs/branchpoints/frotz). Then the commits
> between refs/branchpoints/frotz..refs/heads/frotz identifies the
> commits on the branch. None of the additional restrictions below
> applies when the branch does not have such bottom defined (i.e.
> created by the current git without this extension).
>
> (1) At branch creation, the branchpoint is noted. [...]
>
> (2) You can grow the branch naturally with "commit", "am" and "merge".
> The bottom of the branch does not have to move with these operations.
>
> (3) Operations that alter histories, e.g. "commit --amend", "rebase",
> "reset", while on a branch that records its bottom need to be taught
> to pay attention to not break its bottom. [...]
>
> (4) Operations that browse histories, e.g. "log", "show-branch", while on
> a branch that records its bottom can be taught to pay attention to
> the bottom. [...]
I think this not only changes the model of branches, but also commits,
to some extent. Currently, commit have no intrinsic branch
membership; if you say
git branch foo bar
you cannot distinguish whether the commits on 'bar' were created on
'foo' or on 'bar'. (By git's means; of course the decision would
favour 'master' if I had used that instead.)
Technically your proposal does not change this fact very much; it is
still possible to create "clones" of branches that are
indistinguishable. However, to the *user* I think we would create a
notion that "a commit belongs to one specific branch", in that, during
the course of normal operations, a commit will end up on exactly one
git rev-list --first-parent base..branch
range.
(Not sure if I consider this as an argument in favour or against yet,
but I wanted to point it out anyway.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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