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 think that as
Jeff King p...@peff.net 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
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
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov alexey.mura...@gmail.com 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
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov alexey.mura...@gmail.com 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
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov alexey.mura...@gmail.com 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
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 are making a
Michael Haggerty mhag...@alum.mit.edu 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
Alexey Muranov alexey.mura...@gmail.com 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
On 19 Aug 2012, at 19:38, Junio C Hamano wrote:
Alexey Muranov alexey.mura...@gmail.com 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
Alexey Muranov alexey.mura...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
From: Michael Haggerty mhag...@alum.mit.edu
On 08/17/2012 01:29 AM, Junio C Hamano wrote: Junio C Hamano
gits...@pobox.com 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
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 ultimate
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.
I
Alexey Muranov alexey.mura...@gmail.com 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
16 matches
Mail list logo
