Dear Junio,

On 20 Aug 2012, at 02:26, Junio C Hamano wrote:

> We are not particularly interested in "it is possible" when many
> implementations can all trivially allow it to be "possible"; the
> question is what a sensible solution is among them, and I didn't
> find "a directory with timestamp in its name" a particularly
> sensible way to go.
> Either Jeff's "refname $name's log goes to logs/graveyard/$name~" or
> Michael's "append ~d to each directory component, append ~f to the
> leaf component" that are already proposed will keep "one file per
> name" property to allow us to open once and efficiently read the
> file through.  Why would we want to see an inferiour alternative
> added to the discussion?

I let the others decide if my idea with "timestamp" directories has a 
significant advantage over other proposed solutions or not.  It seemed 
different, so i wanted to add it to the discussion.  I cannot clearly formulate 
an advantage, but i will try to explain why i proposed it.

I would like also to propose another solution for allowing both "next" and 
"next/foo" branches, and to try to explain how it is different from the other 
proposed solutions (unless i missed something).

I would like that the solutions introduce as little new as possible to the 
existing solutions used in similar situation.

The problem of mapping branch names to file paths looks to me very similar to 
the problem of mapping URLs to file paths for static web sites, so i would 
propose to use the same solution: add a special extension to distinguish a file 
from a directory, for example ".branch" and ".tag" (like ".html" in the case of 
URL).  This would allow having both branches "next" and "next/foo" with refs 
stored in files "next.branch" and "next/foo.branch".  This will look very clear 
and familiar to people not specialist in Git, but familiar with static web 
sites.  The only limitation this would introduces is that branch names 
"foo.branch" would need to be forbidden.  If the extension is optional, this 
makes the new rule almost compatible with the current one, except if somebody 
is currently using branches named like "foo.branch" or "next.branch/foo".

For the reflogs of deleted branches, if both "next/foo" and "next" are allowed 
and it is decided to append to the reflogs when a new branch with the same name 
is deleted, then of course "timestamp" directories are useless.  However, i do 
not think that if a branch "tmp" was created and deleted multiple times, all 
its reflogs have to be concatenated into a single file.  So i viewed the 
problem of deleting identically named branches as the problem of deleting files 
under an operating system environment that uses a Trash Bin.  In this case, 
adding a timestamp usually solves the problem.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to