archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <>
To: Julian Phillips <>
Cc: Peter Baumann <>,
Subject: Re: [BUG] git-new-workdir doesn't understand packed refs
Date: Wed, 18 Apr 2007 09:23:14 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Julian Phillips's message of "Wed, 18 Apr 2007 12:55:15 +0100 (BST)")

Julian Phillips <> writes:

>>>  (1) We could by convention declare a worktree whose .git/refs
>>>      is a symlink, and have git-gc and friends check for it, and
>>>      either refuse to run or automatically chdir and run there.
>>>      If we were to do this, we probably should check more than
>>>      just .git/refs but some other symlinks under .git/ as well.
>>>  (2) We could dereference .git/packed-refs, when it is a
>>>      symlink, by hand, just like we dereference a symlink HEAD
>>>      by hand (see resolve_ref() in refs.c), and run the
>>>      creat-to-temp-and-then-rename sequence to update the real
>>>      file that is pointed at by it.
>> Its not all the clear which one is the best, but (2) sounds as the most
>> promosing aproach. Hopefully, I'll have time to cook up a patch this
>> evening.
> Personally I think (1) might be slightly better, in the refuse to run
> form.  gc is a repository operation, not a working directory one - and
> by refusing to run in a workdir this is made clear.  You could print
> out a message that includes the location of the actual repo to be more
> friendly though.

I've seen Peter's patch that attempts to do (2), and I think
that probably is a right direction.  A worktree that borrows a
repository from another worktree is trying to allow you to do
as many things you would normally do in the original worktree,
with a caveat: certain things are less safe and/or confusing and
you must know what you are doing if you use such a setting.

> But whatever solution you go for, you can't use _any_ workdir that
> points at a repo that is having gc run on, either directly or
> indirectly, without risky odd behaviour.

And I think the above is just one of certain things that are
less safe (one "confusing" is that working on the same branch
would result in gremlin updates).  

There still is an issue of what to do if the .git/packed-refs is
a symlink to a symlink.  Peter's patch does a wrong thing, by
creat-then-rename overwriting the symlinked target; at least we
should detect that case and error out, I think.

Recursively dereferencing the symbolic link by hand to a limit
to avoid infinite recursion (error out when we reach the limit)
would be a more elaborate solution that probably is the right
thing to do.

  reply	other threads:[~2007-04-18 16:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-17 16:17 [BUG] git-new-workdir doesn't understand packed refs Peter Baumann
2007-04-17 21:55 ` Julian Phillips
2007-04-18  5:52   ` Peter Baumann
2007-04-18  7:26     ` Julian Phillips
2007-04-18  7:40     ` Junio C Hamano
2007-04-18  8:11       ` Peter Baumann
2007-04-18 11:55         ` Julian Phillips
2007-04-18 16:23           ` Junio C Hamano [this message]
2007-04-18 17:43             ` Peter Baumann
2007-04-18 18:17               ` Junio C Hamano
2007-04-18 18:31                 ` Peter Baumann
2007-04-18 18:42                   ` Junio C Hamano
2007-04-18 21:08                     ` Peter Baumann
2007-04-18 21:31                       ` Junio C Hamano
2007-04-19  5:35                         ` [PATCH] Add test for symlinked .git/packed-refs Peter Baumann
2007-04-19  6:06                           ` Junio C Hamano
2007-04-20 16:52                             ` [PATCH] pack-refs: dereference .git/packed-refs if it is a symlink Peter Baumann
2007-04-21 20:05                               ` Junio C Hamano
2007-04-18 18:43                   ` [BUG] git-new-workdir doesn't understand packed refs Julian Phillips
2007-04-18 10:28       ` [PATCH] pack-refs: dereference .git/packed-refs if it is a symlink Peter Baumann
2007-04-18 16:09         ` Linus Torvalds
2007-04-18 17:47           ` Peter Baumann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).