From: Peter Baumann <email@example.com>
To: Junio C Hamano <firstname.lastname@example.org>
Cc: Julian Phillips <email@example.com>, firstname.lastname@example.org
Subject: Re: [BUG] git-new-workdir doesn't understand packed refs
Date: Wed, 18 Apr 2007 19:43:50 +0200 [thread overview]
Message-ID: <20070418174350.GB5913@xp.machine.xx> (raw)
On Wed, Apr 18, 2007 at 09:23:14AM -0700, Junio C Hamano wrote:
> Julian Phillips <email@example.com> 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.
I thought about the case where packed-refs is a symlink to another symlink
and then decided that it's not worth to implement this because a workdir
should be linked to a _repo_ and not another workdir.
next prev parent reply other threads:[~2007-04-18 17:44 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
2007-04-18 17:43 ` Peter Baumann [this message]
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
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:
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
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 read-only IMAP folder(s) and NNTP newsgroup(s).