Re: A few "linked checkout" niggles

[Eric Sunshine <sunshine@sunshineco.com>]

On Thu, Jul 16, 2015 at 1:24 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Thu, Jul 16, 2015 at 6:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I've tried to set up a non-bare clone of git.git at ~/w/src and
>> attached one of its branches to a separate work tree at ~/w/rerere
>>
>>  ~/w/src$ git worktree add ../rerere jc/rerere
>>
>> Then I tried the "multiple checkout not allowed".
>>
>>  ~/w/src$ git checkout jc/rerere
>>  fatal: 'jc/rerere' is already checked out at '/home/gitster/w/rerere/.git'
>>
>> You see the first "niggle" above.  Do we need "/.git" at the end?
>> That is hopefully merely cosmetic and I am guessing that we can
>> unconditionally drop "/.git" from the end, but maybe there are
>> subtle reasons why it may not be a good idea (e.g. introduces some
>> ambiguities?)

I can't think of any ambiguities which might arise from stripping the
.git suffix. Even when playing with GIT_COMMON_DIR and GIT_WORK_TREE,
I don't notice any ambiguities.

Since I'm already touching this code and am wrapping up v2 of [1], I
can easily plop in a fix for this cosmetic issue.

>> There is another, a more serious one.
>>
>>  ~/w/src$ git fetch ../git.git jc/rerere:jc/rerere
>>
>> This succeeds, without checking if there is a work tree that has it
>> checked out.  I think the safety in "git fetch" that can be disabled
>> by "--update-head-ok" option should be updated to reuse the same
>> protection used by the updated "git checkout".
>>
>> Something to work on for 2.5.x maintenance track, aiming for 2.5.1.
>
> To keep things clear, Eric if you want these they are yours :-) I'll
> focus on the submodule support after i'm done with all my bug fix
> patches.

I want to focus on getting v2 of [1] out and finalized. After that, I
might be able to take a look at the git-fetch issue (but I won't
complain if you get to it first).

[1]: http://thread.gmane.org/gmane.comp.version-control.git/273856