Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19 Aug 2012, at 02:02, Junio C Hamano wrote:

> Alexey Muranov <alexey.muranov@xxxxxxxxx> writes:
> 
>> Excuse 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?
> 
> Decide if it makes sense to break backward compatibility of loose
> ref representation merely to support having a branch "next" and
> another branch "next/foo" in the same repository, and if it does,
> what the new loose ref representation looks like.

I looked again through this thread and tried to understand better the issues.

1. I vote for moving dead reflogs to "logs/graveyard" (or to "logs/deadlogs").

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

3. 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?

/logs/graveyard/yyyy-mm-dd-hhmmss/refs/heads/next/foo

In a sense this is similar to the git storage model: an "atomic" destructive operation creates a timestamped "commit" in logs/graveyard directory.--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]