Re: keeping track of where a patch begins

From: Thomas Rast <trast@student.ethz.ch>
Date: Oct 22, 2009, 08:27 UTC
Message-ID: <200910221027.32739.trast@student.ethz.ch>
In-Reply-To: <7veiow4iqc.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 30 quoted lines

> 
> 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