Peter Baumann <waste.manager@xxxxxx> 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@xxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html