[RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
- From
mhagger@alum.mit.edu <mhagger@alum.mit.edu>
- Date
- Aug 18, 2012, 17:14 UTC
- Message-ID
- <1345310086-20089-1-git-send-email-mhagger@alum.mit.edu>
- In-Reply-To
- <20120719213311.GA20385@sigill.intra.peff.net>
From: Michael Haggerty <mhagger@alum.mit.edu>
On 08/17/2012 01:29 AM, Junio C Hamano wrote:> Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
>> I like the general direction. Perhaps a long distant future >> direction could be to also use the same trick in the ref namespace >> so that we can have 'next' branch itself, and 'next/foo', 'next/bar' >> forks that are based on the 'next' branch at the same time (it >> obviously is a totally unrelated topic)? > > I notice that I was responsible for making this topic veer in the > wrong direction by bringing up a new feature "having 'next' and > 'next/bar' at the same time" which nobody asked. Perhaps we can > drop that for now to simplify the scope of the topic, to bring the > log graveyard back on track?
Given that a flag day would anyway be required to add a d/f-tolerant system, I could live with a separate "graveyard" namespace as originally proposed by Jeff.
However, I still think that as long as we are making a jump, we could try to land closer to the ultimate destination. So here are some patches that apply on top of Jeff's to show what I mean. (Please also note that I made some technical comments about Jeff's patches in an earlier email.)
The first two patches fix a breakage that I see when I apply Jeff's patches to master.
The third changes the implementation of refname_to_graveyard_reflog() and graveyard_reflog_to_refname() and touches up some test cases. It changes the naming convention for dead references to
"$GIT_DIR/logs/refs~d/heads~d/foo~d/bar~d/baz~f"
I.e., the dead reflogs are stored closer to the living. It is not obvious whether the "refs" part of the name should be munged to "refs~d" as I have done, or left unmunged. The argument in favor of munging is that the algorithm is more uniform. On the other hand, extending the same scheme to loose references would produce filenames like
"$GIT_DIR/refs~d/heads~d/foo~d/bar~d/baz~f"
or maybe they should be nested inside of the refs directory like
"$GIT_DIR/refs/refs~d/heads~d/foo~d/bar~d/baz~f"
(which would also give a better place to store top-level reference names).
I structured the patches to apply on top of Jeff's for presentation purposes, but if they are desired it would of course make more sense to squash his and mine together in the obvious way.
I am a little bit worried that there are other test cases that use "git prune" in the belief that it will remove all commits that were referred to by deleted references. The test suite runs cleanly for me with these patches, but before they are integrated we should audit the places where the test suite calls to "git prune" to make sure that they are still testing what they think.
Michael Haggerty (3): t9300: format test in modern style prior to modifying it Delete reflogs for dead references to allow pruning Change naming convention for the reflog graveyard
refs.c | 31 ++++++++++++++++++++++++------- t/t7701-repack-unpack-unreachable.sh | 4 ++-- t/t9300-fast-import.sh | 13 +++++++------ 3 files changed, 33 insertions(+), 15 deletions(-)
-- 1.7.11.3