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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html