Junio C Hamano 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
> obvi
On Thu, Jul 26, 2012 at 10:46:01AM -0700, Junio C Hamano wrote:
> > Bleh. It seems that we did too good a job in coming up with a list of
> > disallowed ref characters; they really are things you don't want in your
> > filenames at all. :)
>
> Why do no need to even worry about ~ vs : vs whatever
Jeff King writes:
> On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote:
>
>> Am 20.07.2012 17:44, schrieb Jeff King:
>> > So I think a suffix like ":d" is probably the least horrible.
>>
>> Not so. It does not work on Windows :-( in the expected way. Trying to
>> open a file with a co
On 26 Jul 2012, at 18:59, Jeff King wrote:
> Not to mention git itself, as it splits up the refs/remotes hierarchy
> into subdirectories. I think deprecating "/" is out of the question.
>
> -Peff
Ok, i guess you know better than me, my vision of Git is probably still too
simplistic.
-Alexey.--
On Thu, Jul 26, 2012 at 06:41:09PM +0200, Matthieu Moy wrote:
> > How about simply deprecating "/" in branch name?
>
> Err, it's not like nobody's using this feature (Junio does a heavy use
> of it in particular) ...
Not to mention git itself, as it splits up the refs/remotes hierarchy
into subd
Alexey Muranov writes:
> On 26 Jul 2012, at 14:47, Nguyen Thai Ngoc Duy wrote:
>
>> So we haven't found any way to present both branches "foo" and
>> "foo/bar" on file system at the same time. How about when we a new
>> branch introduces such a conflict, we push the new branch directly to
>> pack
On 26 Jul 2012, at 14:47, Nguyen Thai Ngoc Duy wrote:
> So we haven't found any way to present both branches "foo" and
> "foo/bar" on file system at the same time. How about when we a new
> branch introduces such a conflict, we push the new branch directly to
> packed-refs? If we need either of th
On Sat, Jul 21, 2012 at 12:09 AM, Jeff King wrote:
> On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote:
>
>> Am 20.07.2012 17:44, schrieb Jeff King:
>> > So I think a suffix like ":d" is probably the least horrible.
>>
>> Not so. It does not work on Windows :-( in the expected way. Try
On Sun, Jul 22, 2012 at 04:40:14PM +0200, Alexey Muranov wrote:
> > 3. Most importantly, it does not resolve D/F conflicts (it has the
> > same problem as "logs/refs/heads/a~"). If you delete "foo/bar", you
> > will end up with "logs/refs/heads/foo/bar@{...}". That will prevent
> > D/
On 22 Jul 2012, at 15:14, Jeff King wrote:
> 3. Most importantly, it does not resolve D/F conflicts (it has the
> same problem as "logs/refs/heads/a~"). If you delete "foo/bar", you
> will end up with "logs/refs/heads/foo/bar@{...}". That will prevent
> D/F conflicts with a new branch
On Sun, Jul 22, 2012 at 01:10:55PM +0200, Alexey Muranov wrote:
> >>> refs/heads/a
> >>> refs/heads/a/b
> >>> refs/heads/a/b/c
> >>>
> >>> will be stored in:
> >>>
> >>> logs/graveyard/refs/heads/a~
> >>> logs/graveyard/refs/heads/a/b~
> >>> logs/graveyard/refs/heads/a/b/c~
> >>>
>
On 22 Jul 2012, at 13:10, Alexey Muranov wrote:
> Sorry if this idea is stupid or if i miss something, but how about putting
> deleted reflogs for
>
> refs/heads/a
> refs/heads/a/b
> refs/heads/a/b/c
>
> to
>
> refs/heads/a@-mm-dd-hhmmss
> refs/heads/a/b@-mm-dd-hhmmss
> refs/heads/a/b
On 20 Jul 2012, at 17:44, Jeff King wrote:
> On Fri, Jul 20, 2012 at 11:49:07AM +0200, Michael Haggerty wrote:
>
>>> This patch moves reflog entries into a special "graveyard"
>>> namespace, and appends a tilde (~) character, which is
>>> not allowed in a valid ref name. This means that the delet
On 20 Jul 2012, at 19:09, Jeff King wrote:
> On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote:
>
>> Am 20.07.2012 17:44, schrieb Jeff King:
>>> So I think a suffix like ":d" is probably the least horrible.
>>
>> Not so. It does not work on Windows :-( in the expected way. Trying to
On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote:
> Am 20.07.2012 17:44, schrieb Jeff King:
> > So I think a suffix like ":d" is probably the least horrible.
>
> Not so. It does not work on Windows :-( in the expected way. Trying to
> open a file with a colon-separated suffix either
Am 20.07.2012 17:44, schrieb Jeff King:
> So I think a suffix like ":d" is probably the least horrible.
Not so. It does not work on Windows :-( in the expected way. Trying to
open a file with a colon-separated suffix either opens a resource fork
on NTFS or fails with "invalid path".
-- Hannes
--
Am 20.07.2012 11:49, schrieb Michael Haggerty:
> Other possibilities (according to git-check-ref-format(1)):
>
> refs/.heads/.a/.b/c
> refs/heads./a./b./c (problematic on some Windows filesystems?)
Yes. Probably all filesystems.
> refs/heads../a../b../c
Same here.
> refs/heads~
On Fri, Jul 20, 2012 at 08:42:57AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > But it would mean that you cannot naively run
> >
> > echo $sha1 >.git/refs/heads/foo
> >
> > anymore. I suspect that the packed-refs conversion rooted out many
> > scripts that did not use update-ref and
On Fri, Jul 20, 2012 at 11:49:07AM +0200, Michael Haggerty wrote:
> >This patch moves reflog entries into a special "graveyard"
> >namespace, and appends a tilde (~) character, which is
> >not allowed in a valid ref name. This means that the deleted
> >reflogs of these refs:
> >
> >refs/heads/
Jeff King writes:
> But it would mean that you cannot naively run
>
> echo $sha1 >.git/refs/heads/foo
>
> anymore. I suspect that the packed-refs conversion rooted out many
> scripts that did not use update-ref and rev-parse to access refs, but
> the above does still work today. So I suspect th
Jeff King writes:
> I noticed I ignored the "discover" and "delete" parts of your paragraph.
> As far as deletion goes, I think we can ignore it; expiring all entries
> is equivalent.
> ...
> In other words, I want to focus on getting the ref-level plumbing right,
> and then we can care about the
On Fri, Jul 20, 2012 at 10:43:37AM -0400, Jeff King wrote:
> > I think the work-around indicates the need for regular users to be
> > able to also discover, prune and delete these logs. Do we have
> > "prune reflog for _this_ ref (or these refs), removing entries that
> > are older than this thre
On Thu, Jul 19, 2012 at 03:36:09PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Only one test needed to be updated; t7701 tries to create
> > unreachable objects by deleting branches. Of course that no
> > longer works, which is the intent of this patch. The test
> > now works around i
On 20 Jul 2012, at 16:26, Jeff King wrote:
> On Fri, Jul 20, 2012 at 12:23:12AM +0200, Alexey Muranov wrote:
>
>> i have no idea about Git source and little idea of how it is working
>> internally, but reading through your message i wonder: wouldn't it be
>> a good idea to timestamp the dead refl
On Fri, Jul 20, 2012 at 12:23:12AM +0200, Alexey Muranov wrote:
> i have no idea about Git source and little idea of how it is working
> internally, but reading through your message i wonder: wouldn't it be
> a good idea to timestamp the dead reflogs ?
Each individual entry in the reflog has its
On 07/19/2012 11:33 PM, Jeff King wrote:
[...]
This cannot be done by simply leaving the reflog files in
place. The ref namespace does not allow D/F conflicts, so a
ref "foo" would block the creation of another ref "foo/bar",
and vice versa. This limitation is acceptable for two refs
to exist sim
Jeff King writes:
> Only one test needed to be updated; t7701 tries to create
> unreachable objects by deleting branches. Of course that no
> longer works, which is the intent of this patch. The test
> now works around it by removing the graveyard logs.
I think the work-around indicates the need
Jeff,
i have no idea about Git source and little idea of how it is working
internally, but reading through your message i wonder: wouldn't it be a good
idea to timestamp the dead reflogs ?
Alexey.
On 19 Jul 2012, at 23:33, Jeff King wrote:
> When a ref is deleted, we completely delete its ref
When a ref is deleted, we completely delete its reflog on
the spot, leaving very little help for the user to reverse
the action. One can sometimes reconstruct the missing
entries based on the HEAD reflog, but not always; the
deleted entries may not have ever been on HEAD (for example,
in the case o
29 matches
Mail list logo
