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 itself, and 'next/foo', 'next/bar'
forks that are based on the 'next' branch at the same
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 them on a
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.--
To
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 in the
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
open a file
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 deleted
reflogs
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~
Putting them in the graveyard namespace
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 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/F conflicts
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
On Thu, Jul 19, 2012 at 03:36:09PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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 threshold?
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Fri, Jul 20, 2012 at 08:42:57AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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.
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
--
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 opens a
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
Jeff King p...@peff.net 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
20 matches
Mail list logo
