Re: keeping track of where a patch begins

From: Nicolas Pitre <nico@fluxnic.net>
Date: Oct 21, 2009, 20:50 UTC
Message-ID: <alpine.LFD.2.00.0910211623370.21460@xanadu.home>
In-Reply-To: <7veiow4iqc.fsf@alter.siamese.dyndns.org>

On Wed, 21 Oct 2009, Junio C Hamano wrote:

Show 20 quoted lines

> Nicolas Pitre <nico@fluxnic.net> writes:
> 
> > On Wed, 21 Oct 2009, E R wrote:
> >
> >> What solutions have you come up with to either to catch or prevent
> >> this from happening? It is possible to determine what node a branch
> >> started from?
> >
> > This can be determined by looking at the gitk output.
> >
> > Also 'git merge-base' can give you that node, given the main branch and 
> > the topic branch.  See documentation about git-merge-base.
> >
> > Then if you need to move a branch to another starting node, then 'git 
> > rebase' is what you need (again the git-rebase documentation is pretty 
> > detailed).
> 
> That is a correct way to diagnose the mistake and recover from it, but
> unfortunately it is a rather weak tool to identify the mistake in the
> first place.

Well... The "mistake" is probably going to be different depending on the work flow used. I don't think there is a generic definition of such mistakes.

In this case, simply having

	if [ $(git merge-base $expected_branch_point $branch) != \
	     $(git rev-parse $expected_branch_point) ]; then
		(complain/refuse the merge of $branch)
	fi

should be quite sufficient as an enforcing proper branch policy. Of course the $expected_branch_point is something that is determined outside of Git.

Show 9 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.

I never came across a situation where such an elaborated scheme was needed to actually record and maintain that information, or could be really useful. And some branches might be built on top of a sub-branch already, making the real branch's bottom the sub-branch's instead in a given context. It all depends on the work flow and the convention used for a project. And the tool has no way to figure that out (is this the real branch bottom or should it be one or more level down?), etc.

> We probably could kill the other bird in the nearby thread that wants to
> add a description to a branch, if this scheme is fully implemented

Well, I think we gain in flexibility by keeping those things separate though. Blending data structures together is not always a good thing.

We have reflog data separate from the refs themselves, so I think that having .git/desc/refs/* containing simple text files would be good enough and simple to implement/use.

Nicolas