archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <>
To: Peter Baumann <>
Cc: Julian Phillips <>
Subject: Re: [BUG] git-new-workdir doesn't understand packed refs
Date: Wed, 18 Apr 2007 14:31:29 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20070418210819.GG5913@xp.machine.xx> (Peter Baumann's message of "Wed, 18 Apr 2007 23:08:20 +0200")

Peter Baumann <> writes:

> On Wed, Apr 18, 2007 at 11:42:24AM -0700, Junio C Hamano wrote:
>> Peter Baumann <> writes:
>> <ot>
>> Getting more and more annoyed by your stupid Mail-Followup-To...
>> I do *not* want to bother Julian with a message that points out
>> a flaw (in my opinion) in YOUR reasoning but you are forcing me
>> to send my message that way, which I have to waste time
>> correcting every time.  Grumble.
>> </ot>
> Hm. Sorry. I don't understand. I'm just pressing 'g' for group reply in
> mutt which should do the right thing; even your mail has a CC to Julian
> set so I _really_ don't understand the problem. I addressed him in the
> begining because he was the author of git-new-workdir. But please
> forgive me if I'm breaking some netiquette rules but I just started to
> hang out activly on mailinglists ...

Because you had Mail-Followup-To: set to point at me and Julian,
when I say "followup", by default I get this in my MUA:

    To: Julian Phillips <>
    Subject: Re: [BUG] git-new-workdir doesn't understand packed refs

Many people prioritize their e-mails depending on where in the
header their name appears (ones that have you on Cc: typically
gets lower priority than the ones addressed specifically to you
by having you on To: line), and if Julian is doing that, sending
my message in which I want to talk to YOU that way would steal
from Julian's time.  So as a general netiquette, I end up hand
fixing it, putting you on To: and demoting Julian to Cc:.

I know why you (or some version of mutt) do so.  It saves you
from filtering incoming duplicates (one addressed to you,
another addressed to the mailing list you subscribe to), but it
is a misfeature.


>> Also, how is the above different from this?
>> 	git init a
>>         cd a ; git gc ; cd ..	# allowed
>> 	git new-workdir a b
>> 	cd b ; git gc ; cd ..	# NOT ALLOWED
> Sorry, you lost me here. Your above sequence _is_ allowed and that was
> just the point of the patch. I lightly tested it that it does the right
> thing, so perhaps I'm missing something?

What I was getting at was that if you do not allow new-workdir
to be done off of a symlinked one, that was like not allowing gc
in a symlinked one.  Both are limitations we _could_ lift.  But
I'd like to take that back, because...

> This is even dissallowed by the code in git-new-workdir (Sorry, I just
> saw it now; otherwise I wouldn't spend so much time in arguing this)):
> # don't link to a workdir
> if test -L "$orig_git/.git/config"
> then
>         die "\"$orig_git\" is a working directory only, please specify" \
>                 "a complete repository."
> fi

... I missed this one.  People cannot make a symlinked one off
of another by using new-workdir script, which means perhaps
something like this on top of your patch would be safe enough.
Sorry for the confusion.

> But with my patch it just works! I really tested it again. The link
> in b/.git/packed-refs -> a/.git/packed-refs (using the example from above)
> isn't broken up and in the new generated packed-refs are stored inside
> the repo a (as they should).

Oh, I never questioned that you made that basic case work.  I
was worried about not making sure the symlink we are looking at
really is the case we are willing to handle, and not erroring
out if that is not the case, perhaps like the attached patch on
top of yours.

An additional test or two in t/t3210 would be nice to accompany
this change.

diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index afa9b5a..1ce4f55 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -123,6 +123,9 @@ int cmd_pack_refs(int argc, const char **argv, const char *prefix)
 			die("readlink failed\n");
 		buf[st.st_size] = '\0';
+		if (!lstat(buf, &st) && S_ISLNK(st.st_mode))
+			die("cannot have doubly symlinked packed-refs file: %s",
+			    ref_file_name);
 		ref_file_name = buf;

  reply	other threads:[~2007-04-18 21:31 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
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 [this message]
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).