From: Michael Haggerty <mhagger@xxxxxxxxxxxx>
On 08/17/2012 01:29 AM, Junio C Hamano wrote:> Junio C Hamano <gitster@xxxxxxxxx> writes:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html