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