{"thread":{"id":"31279","subject":"[RFC 3/3] Change naming convention for the reflog graveyard","startedAt":"2012-08-18T17:14:43Z","lastAt":"2012-08-21T17:56:45Z","messageCount":21,"participants":["mhagger@alum.mit.edu","Junio C Hamano","Alexey Muranov","Michael Haggerty","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197243","messageId":"1345310086-20089-1-git-send-email-mhagger@alum.mit.edu","threadId":"31279","inReplyTo":"20120719213311.GA20385@sigill.intra.peff.net","subject":"[RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-08-18T17:14:43Z","receivedAt":"2012-08-18T17:14:43Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"From: Michael Haggerty \n\nOn 08/17/2012 01:29 AM, Junio C Hamano wrote:> Junio C Hamano writes:\n>> I like the general direction. Perhaps a long distant future\n>> direction could be to also use the same trick in the ref namespace\n>> so that we can have 'next' branch itself, and 'next/foo', 'next/bar'\n>> forks that are based on the 'next' branch at the same time (it\n>> obviously is a totally unrelated topic)?\n> \n> I notice that I was responsible for making this topic veer in the\n> wrong direction by bringing up a new feature \"having 'next' and\n> 'next/bar' at the same time\" which nobody asked. Perhaps we can\n> drop that for now to simplify the scope of the topic, to bring the\n> log graveyard back on track?\n\nGiven that a flag day would anyway be required to add a d/f-tolerant\nsystem, I could live with a separate \"graveyard\" namespace as\noriginally proposed by Jeff.\n\nHowever, I still think that as long as we are making a jump, we could\ntry to land closer to the ultimate destination. So here are some\npatches that apply on top of Jeff's to show what I mean. (Please also\nnote that I made some technical comments about Jeff's patches in an\nearlier email.)\n\nThe first two patches fix a breakage that I see when I apply Jeff's\npatches to master.\n\nThe third changes the implementation of refname_to_graveyard_reflog()\nand graveyard_reflog_to_refname() and touches up some test cases. It\nchanges the naming convention for dead references to\n\n \"$GIT_DIR/logs/refs~d/heads~d/foo~d/bar~d/baz~f\"\n\nI.e., the dead reflogs are stored closer to the living. It is not\nobvious whether the \"refs\" part of the name should be munged to\n\"refs~d\" as I have done, or left unmunged. The argument in favor of\nmunging is that the algorithm is more uniform. On the other hand,\nextending the same scheme to loose references would produce filenames\nlike\n\n \"$GIT_DIR/refs~d/heads~d/foo~d/bar~d/baz~f\"\n\nor maybe they should be nested inside of the refs directory like\n\n \"$GIT_DIR/refs/refs~d/heads~d/foo~d/bar~d/baz~f\"\n\n(which would also give a better place to store top-level reference\nnames).\n\nI structured the patches to apply on top of Jeff's for presentation\npurposes, but if they are desired it would of course make more sense\nto squash his and mine together in the obvious way.\n\nI am a little bit worried that there are other test cases that use\n\"git prune\" in the belief that it will remove all commits that were\nreferred to by deleted references. The test suite runs cleanly for me\nwith these patches, but before they are integrated we should audit the\nplaces where the test suite calls to \"git prune\" to make sure that\nthey are still testing what they think.\n\nMichael Haggerty (3):\n t9300: format test in modern style prior to modifying it\n Delete reflogs for dead references to allow pruning\n Change naming convention for the reflog graveyard\n\n refs.c | 31 ++++++++++++++++++++++++-------\n t/t7701-repack-unpack-unreachable.sh | 4 ++--\n t/t9300-fast-import.sh | 13 +++++++------\n 3 files changed, 33 insertions(+), 15 deletions(-)\n\n-- \n1.7.11.3\n"},{"id":"197244","messageId":"1345310086-20089-2-git-send-email-mhagger@alum.mit.edu","threadId":"31279","inReplyTo":"1345310086-20089-1-git-send-email-mhagger@alum.mit.edu","subject":"[RFC 1/3] t9300: format test in modern style prior to modifying it","fromName":"","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-08-18T17:14:44Z","receivedAt":"2012-08-18T17:14:44Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"From: Michael Haggerty \n\n\nSigned-off-by: Michael Haggerty \n---\n t/t9300-fast-import.sh | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh\nindex 2fcf269..266ae30 100755\n--- a/t/t9300-fast-import.sh\n+++ b/t/t9300-fast-import.sh\n@@ -1698,12 +1698,12 @@ M 160000 $SUBLAST sub\n \n INPUT_END\n \n-test_expect_success \\\n-\t'P: verbatim SHA gitlinks' \\\n-\t'git branch -D sub &&\n-\t git gc && git prune &&\n-\t git fast-import input <\n\nThis test is broken by \"retain reflogs for deleted refs\". Explicitly\ndelete the reflogs in the graveyard to allow the corresponding commits\nto be pruned.\n\nSigned-off-by: Michael Haggerty \n---\n\nProbably there should be a \"git reflog\" subcommand to do this.\n\n t/t9300-fast-import.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh\nindex 266ae30..dc6c67d 100755\n--- a/t/t9300-fast-import.sh\n+++ b/t/t9300-fast-import.sh\n@@ -1700,6 +1700,7 @@ INPUT_END\n \n test_expect_success 'P: verbatim SHA gitlinks' '\n \tgit branch -D sub &&\n+\trm -rf .git/logs/graveyard &&\n \tgit gc && git prune &&\n \tgit fast-import \n\nStore reflogs for dead references among those for live references, in\na scheme that could in the future be extended to prevent\nfile/directory conflicts for live reference names, as well. Store the\nreflog for a dead reference \"refs/foo/bar/baz\" in file\n\"$GIT_DIR/logs/refs~d/heads~d/foo~d/bar~d/baz~f\", where the suffix\n\"~d\" is appended to \"directory\" names and \"~f\" is append to \"file\"\nnames.\n\nSigned-off-by: Michael Haggerty \n---\n refs.c | 31 ++++++++++++++++++++++++-------\n t/t7701-repack-unpack-unreachable.sh | 4 ++--\n t/t9300-fast-import.sh | 2 +-\n 3 files changed, 27 insertions(+), 10 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex 551a0f9..4797b20 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -2580,20 +2580,37 @@ char *shorten_unambiguous_ref(const char *refname, int strict)\n \n char *refname_to_graveyard_reflog(const char *ref)\n {\n-\treturn git_path(\"logs/graveyard/%s~\", ref);\n+\tstatic struct strbuf buf = STRBUF_INIT;\n+\n+\tconst char *p, *slash;\n+\tstrbuf_reset(&buf);\n+\tfor (p = ref; (slash = strchr(p, '/')); p = slash + 1) {\n+\t\tstrbuf_add(&buf, p, slash - p);\n+\t\tstrbuf_addstr(&buf, \"~d/\");\n+\t}\n+\tstrbuf_addstr(&buf, p);\n+\tstrbuf_addstr(&buf, \"~f\");\n+\n+\treturn git_path(\"logs/%s\", buf.buf);\n }\n \n char *graveyard_reflog_to_refname(const char *log)\n {\n \tstatic struct strbuf buf = STRBUF_INIT;\n \n-\tif (!prefixcmp(log, \"graveyard/\"))\n-\t\tlog += 10;\n-\n+\tconst char *p, *slash;\n \tstrbuf_reset(&buf);\n-\tstrbuf_addstr(&buf, log);\n-\tif (buf.len > 0 && buf.buf[buf.len-1] == '~')\n-\t\tstrbuf_setlen(&buf, buf.len - 1);\n+\tfor (p = log; (slash = strchr(p, '/')); p = slash + 1) {\n+\t\tif (slash - p > 2 && slash[-2] == '~' && slash[-1] == 'd')\n+\t\t\tstrbuf_add(&buf, p, slash - p - 2);\n+\t\telse\n+\t\t\tstrbuf_add(&buf, p, slash - p);\n+\t\tstrbuf_addch(&buf, '/');\n+\t}\n+\n+\tstrbuf_addstr(&buf, p);\n+\tif (buf.len > 2 && !strcmp(buf.buf + buf.len - 2, \"~f\"))\n+\t\tstrbuf_setlen(&buf, buf.len - 2);\n \n \treturn buf.buf;\n }\ndiff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh\nindex c06b715..f8d02db 100755\n--- a/t/t7701-repack-unpack-unreachable.sh\n+++ b/t/t7701-repack-unpack-unreachable.sh\n@@ -40,7 +40,7 @@ test_expect_success '-A with -d option leaves unreachable objects unpacked' '\n \t# now expire the reflog, while keeping reachable ones but expiring\n \t# unreachables immediately; also remove any graveyard reflogs\n \t# from deleted branches that would keep things reachable\n-\trm -rf .git/logs/graveyard &&\n+\trm -rf .git/logs/*~? &&\n \ttest_tick &&\n \tsometimeago=$(( $test_tick - 10000 )) &&\n \tgit reflog expire --expire=$sometimeago --expire-unreachable=$test_tick --all &&\n@@ -78,7 +78,7 @@ test_expect_success '-A without -d option leaves unreachable objects packed' '\n \ttest 1 = $(ls -1 .git/objects/pack/pack-*.pack | wc -l) &&\n \tpackfile=$(ls .git/objects/pack/pack-*.pack) &&\n \tgit branch -D transient_branch &&\n-\trm -rf .git/logs/graveyard &&\n+\trm -rf .git/logs/*~? &&\n \ttest_tick &&\n \tgit repack -A -l &&\n \ttest ! -f \"$fsha1path\" &&\ndiff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh\nindex dc6c67d..8d88f5f 100755\n--- a/t/t9300-fast-import.sh\n+++ b/t/t9300-fast-import.sh\n@@ -1700,7 +1700,7 @@ INPUT_END\n \n test_expect_success 'P: verbatim SHA gitlinks' '\n \tgit branch -D sub &&\n-\trm -rf .git/logs/graveyard &&\n+\trm -rf .git/logs/*~? &&\n \tgit gc && git prune &&\n \tgit fast-import Given that a flag day would anyway be required to add a d/f-tolerant\n> system, I could live with a separate \"graveyard\" namespace as\n> originally proposed by Jeff.\n>\n> However, I still think that as long as we are making a jump, we could\n> try to land closer to the ultimate destination.\n\nDo we _know_ already what the \"ultimate destination\" looks like? \n\nIf the answer is yes, then I agree, but otherwise, I doubt it is a\ngood idea to introduce unnecessary complexity to the system that may\nhave to be ripped out and redone.\n\nI didn't get the impression that we know the \"ultimate destination\"\nfrom the previous discussion, especially if we discount the tangent\naround \"having next and next/foo at the same time\" which was on\nnobody's wish, but I may be misremembering things.\n"},{"id":"197266","messageId":"B88EFDF9-0AB6-49AC-87E5-7515B99AE601@gmail.com","threadId":"31279","inReplyTo":"7vboi8rl2q.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-18T21:11:33Z","receivedAt":"2012-08-18T21:11:33Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"On 18 Aug 2012, at 22:39, Junio C Hamano wrote:\n\n> Do we _know_ already what the \"ultimate destination\" looks like? \n> \n> If the answer is yes, then I agree, but otherwise, I doubt it is a\n> good idea to introduce unnecessary complexity to the system that may\n> have to be ripped out and redone.\n> \n> I didn't get the impression that we know the \"ultimate destination\"\n> from the previous discussion, especially if we discount the tangent\n> around \"having next and next/foo at the same time\" which was on\n> nobody's wish, but I may be misremembering things.\n\nExcuse me if i miss something again, but i might be willing to discuss the \"ultimate destination\". Could you possibly state in simple terms what the problem with determining the \"ultimate destination\" is? I hope my opinion might be useful because i do not know anything about the actual implementation of Git, but for a while i thought i was understanding it's intended mathematical model, until i ran into unexpected for me default behavior of not pruning when fetching.\n\nTo just give a quick idea of my ideas, i thought that 'fetching' in Git was an inevitable evil that stands apart from other operations and is necessary only because the computer communication on Earth is not sufficiently developed to keep all Git repositories constantly in sync, and because one might prefer to work with a somewhat dated snapshot of a remote than with the constantly changing current version. I thought \"snapshot\" could be a good alternative name for \"fetch\".\n\n-Alexey."},{"id":"197273","messageId":"7vehn3rbom.fsf@alter.siamese.dyndns.org","threadId":"31279","inReplyTo":"B88EFDF9-0AB6-49AC-87E5-7515B99AE601@gmail.com","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-19T00:02:33Z","receivedAt":"2012-08-19T00:02:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexey Muranov writes:\n\n> On 18 Aug 2012, at 22:39, Junio C Hamano wrote:\n>\n>> Do we _know_ already what the \"ultimate destination\" looks like? \n>> \n>> If the answer is yes, then I agree, but otherwise, I doubt it is a\n>> good idea to introduce unnecessary complexity to the system that may\n>> have to be ripped out and redone.\n>> \n>> I didn't get the impression that we know the \"ultimate destination\"\n>> from the previous discussion, especially if we discount the tangent\n>> around \"having next and next/foo at the same time\" which was on\n>> nobody's wish, but I may be misremembering things.\n>\n> Excuse me if i miss something again, but i might be willing to\n> discuss the \"ultimate destination\". Could you possibly state in\n> simple terms what the problem with determining the \"ultimate\n> destination\" is?\n\nDecide if it makes sense to break backward compatibility of loose\nref representation merely to support having a branch \"next\" and\nanother branch \"next/foo\" in the same repository, and if it does,\nwhat the new loose ref representation looks like.\n\n> I hope my opinion might be useful because i do not know anything\n> about the actual implementation of Git,...\n\nThat sounds like contradiction.\n\n> To just give a quick idea of my ideas, i thought that 'fetching'\n> in Git was an inevitable evil that stands apart from other\n> operations and is necessary only because the computer\n> communication on Earth is not sufficiently developed to keep all\n> Git repositories constantly in sync,...\n\nIt is a feature, not a symptom of an insufficiently developed\ntechnology, that I do not have to know what random tweaks and\nexperiments are done in repositories of 47 thousands people who\nclone from me, and I can sync with any one of them only when I know\nthere is something worth looking at when I say \"git fetch\".\n"},{"id":"197277","messageId":"AA92444F-B359-4C46-A1E2-13049C44C6D9@gmail.com","threadId":"31279","inReplyTo":"7vehn3rbom.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-19T07:07:35Z","receivedAt":"2012-08-19T07:07:35Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"On 19 Aug 2012, at 02:02, Junio C Hamano wrote:\n\n> Alexey Muranov writes:\n> \n>> I hope my opinion might be useful because i do not know anything\n>> about the actual implementation of Git,...\n> \n> That sounds like contradiction.\n\nI think that the implementation (the code), the model, and the interface are independent.\nOn the top level, for example, one does not need to know how commit storage is optimized, it is enough to understand that each commit is a snapshot of a subtree in a file directory.\n\n>> To just give a quick idea of my ideas, i thought that 'fetching'\n>> in Git was an inevitable evil that stands apart from other\n>> operations and is necessary only because the computer\n>> communication on Earth is not sufficiently developed to keep all\n>> Git repositories constantly in sync,...\n> \n> It is a feature, not a symptom of an insufficiently developed\n> technology, that I do not have to know what random tweaks and\n> experiments are done in repositories of 47 thousands people who\n> clone from me, and I can sync with any one of them only when I know\n> there is something worth looking at when I say \"git fetch\".\n\nCurrently, one of the main functions of 'fetch', apart from changing the remote tracking branches, is downloading the remote objects. This is necessary because of an insufficiently developed technology.\n\nThe other main function is changing the local copies of remote branches (changing the remote tracking branches), this is what i described as \"taking a snapshot\".\n\nI did not understand what you meant by\n\n \"I do not have to know what random tweaks and experiments are done in repositories of 47 thousands people who clone from me, and I can sync with any one of them only when I know there is something worth looking at when I say \"git fetch\".\"\n\nHow is it possible to know and not to know what is going on in the remote repository in the same time?\n\n-Alexey."},{"id":"197278","messageId":"49E12233-CD0E-410A-81BC-964B6CBE7DE8@gmail.com","threadId":"31279","inReplyTo":"7vehn3rbom.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-19T07:15:26Z","receivedAt":"2012-08-19T07:15:26Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"On 19 Aug 2012, at 02:02, Junio C Hamano wrote:\n\n> Alexey Muranov writes:\n> \n>> I hope my opinion might be useful because i do not know anything\n>> about the actual implementation of Git,...\n> \n> That sounds like contradiction.\n\nI meant that i am psychologically not attached to the current behavior, and may provide a naïve view point, if you like.\n\n-Alexey."},{"id":"197282","messageId":"A15D5621-7EF5-4409-967A-0DA20B007899@gmail.com","threadId":"31279","inReplyTo":"7vehn3rbom.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-19T11:28:01Z","receivedAt":"2012-08-19T11:28:01Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"On 19 Aug 2012, at 02:02, Junio C Hamano wrote:\n\n> Alexey Muranov writes:\n> \n>> Excuse me if i miss something again, but i might be willing to\n>> discuss the \"ultimate destination\". Could you possibly state in\n>> simple terms what the problem with determining the \"ultimate\n>> destination\" is?\n> \n> Decide if it makes sense to break backward compatibility of loose\n> ref representation merely to support having a branch \"next\" and\n> another branch \"next/foo\" in the same repository, and if it does,\n> what the new loose ref representation looks like.\n\nI looked again through this thread and tried to understand better the issues.\n\n1. I vote for moving dead reflogs to \"logs/graveyard\" (or to \"logs/deadlogs\").\n\n2. I think that allowing both \"next\" and \"next/foo\" complicates the mapping from branch names to file paths, and it does not seem necessary if dead reflogs are moved away to \"graveyard\" anyway.\n\n3. There remains the question what to do with dead reflogs for different branches having the same name. Maybe, keep the death date and time under the graveyard directory and not allow the user to delete 2 times in less than 1 second?\n\n/logs/graveyard/yyyy-mm-dd-hhmmss/refs/heads/next/foo\n\nIn a sense this is similar to the git storage model: an \"atomic\" destructive operation creates a timestamped \"commit\" in logs/graveyard directory."},{"id":"197284","messageId":"5030E7D6.8020206@alum.mit.edu","threadId":"31279","inReplyTo":"7vboi8rl2q.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-08-19T13:19:18Z","receivedAt":"2012-08-19T13:19:18Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/18/2012 10:39 PM, Junio C Hamano wrote:\n> mhagger@alum.mit.edu writes:\n> \n>> Given that a flag day would anyway be required to add a d/f-tolerant\n>> system, I could live with a separate \"graveyard\" namespace as\n>> originally proposed by Jeff.\n>>\n>> However, I still think that as long as we are making a jump, we could\n>> try to land closer to the ultimate destination.\n> \n> Do we _know_ already what the \"ultimate destination\" looks like? \n\nNo; we can only guess. I just wanted to submit some code so that the\nexistence/absence of code would not prejudice the decision.\n\n> If the answer is yes, then I agree, but otherwise, I doubt it is a\n> good idea to introduce unnecessary complexity to the system that may\n> have to be ripped out and redone.\n> \n> I didn't get the impression that we know the \"ultimate destination\"\n> from the previous discussion, especially if we discount the tangent\n> around \"having next and next/foo at the same time\" which was on\n> nobody's wish, but I may be misremembering things.\n\nIt's been a wish of mine, but it's pretty low priority. I've also\nbrainstormed about some other changes that could be connected with a new\nrepo format:\n\n* Allow \"deleted\" loose references (for example denoted by value 0{40})\nthat override packed references with the same name. This would remove\nthe need to rewrite the packed-refs file when a reference is deleted.\n(A prerequisite for this change would be to allow next and next/foo at\nthe same time.)\n\n* Push HEAD and its friends down out of $GIT_DIR into a\nreference-specific directory.\n\n* Rename lock files to look less like reference names (e.g., something\nlike \"refs/foo~lock\" instead of \"refs/foo.lock\").\n\n* Somehow munge reference names in a way to avoid other filesystem\nlimitations -- e.g., case insensitivity, filenames like \"com\" and \"prn\"\nor with multiple dots under Windows.\n\n* ...or maybe a packed-refs file that can (usually) be updated in-place,\nand get rid of loose references entirely.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"197287","messageId":"7vlihaq22v.fsf@alter.siamese.dyndns.org","threadId":"31279","inReplyTo":"5030E7D6.8020206@alum.mit.edu","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-19T16:27:36Z","receivedAt":"2012-08-19T16:27:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> It's been a wish of mine, but it's pretty low priority. I've also\n> brainstormed about some other changes that could be connected with a new\n> repo format:\n>\n> * Allow \"deleted\" loose references (for example denoted by value 0{40})\n> that override packed references with the same name. This would remove\n> the need to rewrite the packed-refs file when a reference is deleted.\n> (A prerequisite for this change would be to allow next and next/foo at\n> the same time.)\n\nWe would need to think the performance implications through of the\napproach; it tempts us to accumulate the loose \"removed\" markers in\nthe hope that it would be an improvement than having to rewrite the\npacked-refs over and over, and without numbers to back that theory\nup, we may be worsening the system without knowing.\n\nHaving said that, it is an interesting idea. I wouldn't use 0{40} as\nthe sentinel value but rather use letters outside [0-9a-f], though.\n\n> * Push HEAD and its friends down out of $GIT_DIR into a\n> reference-specific directory.\n\nNot going to happen for several years, I am afraid, as I think many\ncasual tools do an equivalent of \"test -f $DIR/HEAD\" to see if $DIR\nis a repository; even our own gitweb does so.\n\nWe should advertise an easy way for scripted Porcelains to directly\nask is_git_directory().\n\n> * Rename lock files to look less like reference names (e.g., something\n> like \"refs/foo~lock\" instead of \"refs/foo.lock\").\n\nIf you do the ~d/~f thing, foo.lock becomes a non-issue, no?\n\n> * Somehow munge reference names in a way to avoid other filesystem\n> limitations -- e.g., case insensitivity, filenames like \"com\" and \"prn\"\n> or with multiple dots under Windows.\n\nVery interesting. I however am afraid that the users and the\nprojects will learn to avoid the problematic names a lot sooner than\nsuch a change will be implemented to make the issue go away (or they\nhave already learned long time ago), and the end result may end up\nsolving a non-issue only to make the output from \"find .git/refs\"\neven more unreadable.\n\n> * ...or maybe a packed-refs file that can (usually) be updated in-place,\n> and get rid of loose references entirely.\n\nI find this equally intriguing as your \"deleted\" one above.\n"},{"id":"197292","messageId":"7v1uj2pysd.fsf@alter.siamese.dyndns.org","threadId":"31279","inReplyTo":"A15D5621-7EF5-4409-967A-0DA20B007899@gmail.com","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-19T17:38:42Z","receivedAt":"2012-08-19T17:38:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexey Muranov writes:\n\n> 2. I think that allowing both \"next\" and \"next/foo\" complicates\n> the mapping from branch names to file paths, and it does not seem\n> necessary if dead reflogs are moved away to \"graveyard\" anyway.\n\nIt is unclear why the first two lines above leads to the conclusion\n\"it does not seem necessary\" (but honestly, I do not particularly\ncare).\n\n> 3. There remains the question what to do with dead reflogs for\n> different branches having the same name. Maybe, keep the death\n> date and time under the graveyard directory and not allow the user\n> to delete 2 times in less than 1 second?\n>\n> /logs/graveyard/yyyy-mm-dd-hhmmss/refs/heads/next/foo\n\nHow would that help us in what way?\n\nWhen I ask \"git log -g next/foo\" for the \"next/foo\" branch that\ncurrently exists, I want to see the update history of its tip since\nI created it for the last time, and then an entry that says I\ncreated it at such and such time. If I used to have the branch\nbefore but deleted, then the output should be followed by another\nentry that says I deleted it at such and such time, followed by the\nhistory of the tip updates.\n"},{"id":"197303","messageId":"9E4BBC27-5B26-4048-93D4-FE02C550F4E2@gmail.com","threadId":"31279","inReplyTo":"7v1uj2pysd.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-19T22:09:16Z","receivedAt":"2012-08-19T22:09:16Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"On 19 Aug 2012, at 19:38, Junio C Hamano wrote:\n\n> Alexey Muranov writes:\n> \n>> 2. I think that allowing both \"next\" and \"next/foo\" complicates\n>> the mapping from branch names to file paths, and it does not seem\n>> necessary if dead reflogs are moved away to \"graveyard\" anyway.\n> \n> It is unclear why the first two lines above leads to the conclusion\n> \"it does not seem necessary\" (but honestly, I do not particularly\n> care).\n\nI thought that the first reason that allowing \"next\" and \"next/foo\" seemed necessary was avoiding conflicts with dead reflogs or between dead reflogs. If dead reflog for \"next/foo\" is moved away, it will not conflict with a new one for \"next\". There remains a problem with a conflict between dead \"next/foo\" and dead \"next\". This can be solved as Jeff suggested by adding special \"escape\" symbols, or as i suggested below, by keeping reflogs deleted on different occasions in different \"timestamp\" directories.\n\n>> 3. There remains the question what to do with dead reflogs for\n>> different branches having the same name. Maybe, keep the death\n>> date and time under the graveyard directory and not allow the user\n>> to delete 2 times in less than 1 second?\n>> \n>> /logs/graveyard/yyyy-mm-dd-hhmmss/refs/heads/next/foo\n> \n> How would that help us in what way?\n> \n> When I ask \"git log -g next/foo\" for the \"next/foo\" branch that\n> currently exists, I want to see the update history of its tip since\n> I created it for the last time, and then an entry that says I\n> created it at such and such time. If I used to have the branch\n> before but deleted, then the output should be followed by another\n> entry that says I deleted it at such and such time, followed by the\n> history of the tip updates.\n\nI only suggested how to resolve conflicts between dead reflogs in graveyard if \"next\" and \"next/foo\" cannot coexist.\nFor example, if first \"next/foo\" was created and deleted, and then \"next\" was created and deleted. It also seems nice to me to have dead reflogs for different identically named branches (created and deleted independently) in separate files.\n\nIt is possible to collect the information for \"git log -g next/foo\" by looking through all \"timestamp\" subdirectories in graveyard.\n\n-Alexey."},{"id":"197309","messageId":"7vobm6o1cu.fsf@alter.siamese.dyndns.org","threadId":"31279","inReplyTo":"9E4BBC27-5B26-4048-93D4-FE02C550F4E2@gmail.com","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-20T00:26:09Z","receivedAt":"2012-08-20T00:26:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexey Muranov writes:\n\n> I only suggested how to resolve conflicts between dead reflogs in\n> graveyard if \"next\" and \"next/foo\" cannot coexist.\n\nBut Jeff's patch series already has the support for a case where you\ndelete next (graveyard gets 'next'), create next/foo and then delete\nthat (graveyard gets 'next/foo', too) anyway (check the list archive\nbefore posting). It is a solved problem.\n\n> It is possible to collect the information for \"git log -g\n> next/foo\" by looking through all \"timestamp\" subdirectories in\n> graveyard.\n\nIt is possible if you wrote a new file every time you add one entry\nto reflog, or if you created a directory with timestamp in its name\nand wrote a new file there, too.\n\nWe are not particularly interested in \"it is possible\" when many\nimplementations can all trivially allow it to be \"possible\"; the\nquestion is what a sensible solution is among them, and I didn't\nfind \"a directory with timestamp in its name\" a particularly\nsensible way to go.\n\nEither Jeff's \"refname $name's log goes to logs/graveyard/$name~\" or\nMichael's \"append ~d to each directory component, append ~f to the\nleaf component\" that are already proposed will keep \"one file per\nname\" property to allow us to open once and efficiently read the\nfile through. Why would we want to see an inferiour alternative\nadded to the discussion?\n"},{"id":"197313","messageId":"7v7gsunzpk.fsf@alter.siamese.dyndns.org","threadId":"31279","inReplyTo":"7vobm6o1cu.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-20T01:01:43Z","receivedAt":"2012-08-20T01:01:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Either Jeff's \"refname $name's log goes to logs/graveyard/$name~\" or\n> Michael's \"append ~d to each directory component, append ~f to the\n> leaf component\" that are already proposed will keep \"one file per\n> name\" property to allow us to open once and efficiently read the\n> file through. Why would we want to see an inferiour alternative\n> added to the discussion?\n\nNote that there may be some \"other\" advantage I am not seeing in the\n\"directory with timestamp in its name\"; if it is a big enough\nadvantage over what have already been proposed, then that would be a\nvalid reason why we may want to see it as an alternative (and at\nthat point, it is no longer inferior). That is the reason why I\nasked \"How would that help us in what way?\"\n"},{"id":"197335","messageId":"62FFD304-1902-4D69-9287-ECD1E32BABC9@gmail.com","threadId":"31279","inReplyTo":"7vobm6o1cu.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-20T11:32:22Z","receivedAt":"2012-08-20T11:32:22Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"Dear Junio,\n\nOn 20 Aug 2012, at 02:26, Junio C Hamano wrote:\n\n> We are not particularly interested in \"it is possible\" when many\n> implementations can all trivially allow it to be \"possible\"; the\n> question is what a sensible solution is among them, and I didn't\n> find \"a directory with timestamp in its name\" a particularly\n> sensible way to go.\n> \n> Either Jeff's \"refname $name's log goes to logs/graveyard/$name~\" or\n> Michael's \"append ~d to each directory component, append ~f to the\n> leaf component\" that are already proposed will keep \"one file per\n> name\" property to allow us to open once and efficiently read the\n> file through. Why would we want to see an inferiour alternative\n> added to the discussion?\n\nI 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.\n\nI 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).\n\nI would like that the solutions introduce as little new as possible to the existing solutions used in similar situation.\n\nThe 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 n\n amed like \"foo.branch\" or \"next.branch/foo\".\n\nFor 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.\n\n-Alexey."},{"id":"197336","messageId":"A42CEB6A-5951-4869-B890-92BDD2361EC1@gmail.com","threadId":"31279","inReplyTo":"62FFD304-1902-4D69-9287-ECD1E32BABC9@gmail.com","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Alexey Muranov","fromEmail":"alexey.muranov@gmail.com","sentAt":"2012-08-20T11:57:30Z","receivedAt":"2012-08-20T11:57:30Z","isPatch":false,"sender":{"key":"alexey.muranov@gmail.com","avatar":"https://gravatar.com/avatar/15ecd60a4d31cd6b05b9db40739c8c0db30049d238dd6dd26a0c4dd876577648?d=mp&s=160"},"body":"On 20 Aug 2012, at 13:32, Alexey Muranov wrote:\n\n> 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\n named like \"foo.branch\" or \"next.branch/foo\".\n\nAnother possible choice for the extensions: \".~br\" and \".~tg\" (to keep readability of file names and allow all currently allowed branch names)."},{"id":"197519","messageId":"20120821082719.GA13252@sigill.intra.peff.net","threadId":"31279","inReplyTo":"7vboi8rl2q.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-08-21T08:27:19Z","receivedAt":"2012-08-21T08:27:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 18, 2012 at 01:39:41PM -0700, Junio C Hamano wrote:\n\n> mhagger@alum.mit.edu writes:\n> \n> > Given that a flag day would anyway be required to add a d/f-tolerant\n> > system, I could live with a separate \"graveyard\" namespace as\n> > originally proposed by Jeff.\n> >\n> > However, I still think that as long as we are making a jump, we could\n> > try to land closer to the ultimate destination.\n> \n> Do we _know_ already what the \"ultimate destination\" looks like? \n> \n> If the answer is yes, then I agree, but otherwise, I doubt it is a\n> good idea to introduce unnecessary complexity to the system that may\n> have to be ripped out and redone.\n> \n> I didn't get the impression that we know the \"ultimate destination\"\n> from the previous discussion, especially if we discount the tangent\n> around \"having next and next/foo at the same time\" which was on\n> nobody's wish, but I may be misremembering things.\n\nSorry for the slow response on this topic; I was traveling all last week\nand am still catching up with emails.\n\nI don't think we know what the ultimate destination looks like. If I had\nto choose, it would probably be something like:\n\n refs/heads/next.ref\n refs/heads/next/foo.ref\n\nwhich is easy to read and manipulate. But this is not compatible with\nthe current system, because:\n\n 1. It cannot use \".ref\", as that is allowed in ref names currently.\n\n 2. This can't co-exist with existing, non-tweaked refs, since\n \"refs/heads/next\" would still conflict (you'd have to instead do\n \"refs/heads.dir/next.dir/foo\".\n\nBut since making a change like this would involve bumping the\nrepositoryformatversion flag _anyway_, so at that point we don't really\nhave to care about compatibility, and we are free to design what looks\ngood.\n\nSo in other words, I do not think any ultimate destination that I find\npalatable would be achievable without making the full format jump\nanyway. If all things were equal, I'd say there is no reason not to get\nas close as we can. But I find some of the proposals significantly less\nreadable (in particular, the directory-munging is IMHO much harder to\nread). And it is not as if it is buying us anything; you still have to\nmake a magic translation between a dead log and a live one.\n\nAnother option I've considered is simply holding back the graveyard\ntopic, working on the d/f tolerant storage, and then implementing the\ngraveyards on top (which is basically free at that point). But as you\nnote, it is not really a commonly-requested feature. If it were easy,\nI'd say let's do it. But the idea of bumping repositoryformatversion for\nthe first time in git's history just to add a feature nobody wants is\nnot very appealing to me.\n\n-Peff\n"},{"id":"197520","messageId":"20120821083345.GB13252@sigill.intra.peff.net","threadId":"31279","inReplyTo":"1345310086-20089-3-git-send-email-mhagger@alum.mit.edu","subject":"Re: [RFC 2/3] Delete reflogs for dead references to allow pruning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-08-21T08:33:45Z","receivedAt":"2012-08-21T08:33:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 18, 2012 at 07:14:45PM +0200, mhagger@alum.mit.edu wrote:\n\n> From: Michael Haggerty \n> \n> This test is broken by \"retain reflogs for deleted refs\". Explicitly\n> delete the reflogs in the graveyard to allow the corresponding commits\n> to be pruned.\n> \n> Signed-off-by: Michael Haggerty \n> ---\n> \n> Probably there should be a \"git reflog\" subcommand to do this.\n> \n> t/t9300-fast-import.sh | 1 +\n> 1 file changed, 1 insertion(+)\n> \n> diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh\n> index 266ae30..dc6c67d 100755\n> --- a/t/t9300-fast-import.sh\n> +++ b/t/t9300-fast-import.sh\n> @@ -1700,6 +1700,7 @@ INPUT_END\n> \n> test_expect_success 'P: verbatim SHA gitlinks' '\n> \tgit branch -D sub &&\n> +\trm -rf .git/logs/graveyard &&\n\nI think \"git reflog expire --expire=now refs/heads/sub\" would be less\nleaky. That didn't work in my initial version, but it obviously should.\nI'll include a tweaked version of your fix when I re-roll.\n\n-Peff\n"},{"id":"197543","messageId":"7v4nnwdt7m.fsf@alter.siamese.dyndns.org","threadId":"31279","inReplyTo":"20120821082719.GA13252@sigill.intra.peff.net","subject":"Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-21T17:56:45Z","receivedAt":"2012-08-21T17:56:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So in other words, I do not think any ultimate destination that I find\n> palatable would be achievable without making the full format jump\n> anyway. If all things were equal, I'd say there is no reason not to get\n> as close as we can. But I find some of the proposals significantly less\n> readable (in particular, the directory-munging is IMHO much harder to\n> read). And it is not as if it is buying us anything; you still have to\n> make a magic translation between a dead log and a live one.\n\nYes, that is where the earlier comment of mine on this topic came from.\n\n> Another option I've considered is simply holding back the graveyard\n> topic, working on the d/f tolerant storage, and then implementing the\n> graveyards on top (which is basically free at that point). But as you\n> note, it is not really a commonly-requested feature. If it were easy,\n> I'd say let's do it. But the idea of bumping repositoryformatversion for\n> the first time in git's history just to add a feature nobody wants is\n> not very appealing to me.\n\nAmen.\n"}]}