Jeff King writes:
> So in other words, I do not think any ultimate destination that I find
> palatable would be achievable without making the full format jump
> anyway. If all things were equal, I'd say there is no reason not to get
> as close as we can. But I find some of the proposals significa
On Sat, Aug 18, 2012 at 01:39:41PM -0700, Junio C Hamano wrote:
> mhag...@alum.mit.edu writes:
>
> > 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 thi
On 20 Aug 2012, at 13:32, Alexey Muranov wrote:
> 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
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 i
Junio C Hamano writes:
> 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
Alexey Muranov writes:
> I only suggested how to resolve conflicts between dead reflogs in
> graveyard if "next" and "next/foo" cannot coexist.
But Jeff's patch series already has the support for a case where you
delete next (graveyard gets 'next'), create next/foo and then delete
that (graveyar
On 19 Aug 2012, at 19:38, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> 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.
>
> It is unclear
Alexey Muranov writes:
> 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.
It is unclear why the first two lines above leads to the conclusion
"it d
Michael Haggerty writes:
> It's been a wish of mine, but it's pretty low priority. I've also
> brainstormed about some other changes that could be connected with a new
> repo format:
>
> * Allow "deleted" loose references (for example denoted by value 0{40})
> that override packed references wit
On 08/18/2012 10:39 PM, Junio C Hamano wrote:
> mhag...@alum.mit.edu writes:
>
>> 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 ar
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov 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?
>
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> I hope my opinion might be useful because i do not know anything
>> about the actual implementation of Git,...
>
> That sounds like contradiction.
I meant that i am psychologically not attached to the current behavio
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> I hope my opinion might be useful because i do not know anything
>> about the actual implementation of Git,...
>
> That sounds like contradiction.
I think that the implementation (the code), the model, and the interf
Alexey Muranov writes:
> On 18 Aug 2012, at 22:39, Junio C Hamano wrote:
>
>> Do we _know_ already what the "ultimate destination" looks like?
>>
>> If the answer is yes, then I agree, but otherwise, I doubt it is a
>> good idea to introduce unnecessary complexity to the system that may
>> hav
On 18 Aug 2012, at 22:39, Junio C Hamano wrote:
> Do we _know_ already what the "ultimate destination" looks like?
>
> If the answer is yes, then I agree, but otherwise, I doubt it is a
> good idea to introduce unnecessary complexity to the system that may
> have to be ripped out and redone.
>
mhag...@alum.mit.edu writes:
> 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 u
16 matches
Mail list logo
