Re: [BUG] git-new-workdir doesn't understand packed refs

[Junio C Hamano <junkio@cox.net>]

Peter Baumann <waste.manager@gmx.de> 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>

> On Wed, Apr 18, 2007 at 11:17:43AM -0700, Junio C Hamano wrote:
>> Peter Baumann <waste.manager@gmx.de> writes:
>> ...
>> > 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.
>> 
>> That's incredibly weak, as the initial motivation of this patch
>> is that you did not want to say "you should run gc only in the
>> _repo_ not in workdir".
>
> Yes. That's my motivation and it works right now
>
> 	git init a
> 	<hack, hack, hack,>
> 	git commit -a
>
> 	git-new-workdir a b 	# allowed
> 	git-new-workdir a c	# allowed
>
> 	git-new-workdir b d	# NOT ALLOWED

But I do not think you are disallowing it; instead you are
making the same problem appear without telling the user.

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

You are saying "you should run workdir only in the _repo_ not in
workdir".

As I already said, certain things work differently between a
proper repository and a worktree that borrows .git/refs from a
proper repository, and you always have to know what you are
doing when you use such a setup.  If your goal is to minimize
the difference, I do not think it makes much sense to allow gc
and not allow new-workdir.

On the other hand, if we admit that things work differently, I
think erroring out gc or pack-refs when we see .git/packed-refs
is a symbolic link is much simpler, less error prone and easier
to explain.