On Wed, 21 Oct 2009, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxxxxxx> 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. > 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 -- 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