git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* A few "linked checkout" niggles
@ 2015-07-15 23:13 Junio C Hamano
  2015-07-16  5:24 ` Duy Nguyen
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Junio C Hamano @ 2015-07-15 23:13 UTC (permalink / raw)
  To: Nguyễn Thái Ngọc Duy; +Cc: Eric Sunshine, git

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?)

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.

Thanks.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
@ 2015-07-16  5:24 ` Duy Nguyen
  2015-07-16  5:40   ` Eric Sunshine
  2015-07-16 20:39 ` Junio C Hamano
  2015-07-17 12:27 ` Michael J Gruber
  2 siblings, 1 reply; 11+ messages in thread
From: Duy Nguyen @ 2015-07-16  5:24 UTC (permalink / raw)
  To: Eric Sunshine; +Cc: Git Mailing List, Junio C Hamano

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?)
>
> 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.
-- 
Duy

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-16  5:24 ` Duy Nguyen
@ 2015-07-16  5:40   ` Eric Sunshine
  0 siblings, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-16  5:40 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
  2015-07-16  5:24 ` Duy Nguyen
@ 2015-07-16 20:39 ` Junio C Hamano
  2015-07-16 23:13   ` Duy Nguyen
  2015-07-17 12:27 ` Michael J Gruber
  2 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2015-07-16 20:39 UTC (permalink / raw)
  To: Nguyễn Thái Ngọc Duy; +Cc: Eric Sunshine, git

Also in a linked checkout of git.git itself, t5601.21 seems to fail
with:

fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
not ok 21 - clone respects global branch.autosetuprebase
#
#               (
#                       test_config="$HOME/.gitconfig" &&
#                       git config -f "$test_config" branch.autosetuprebase remote &&
#                       rm -fr dst &&
#                       git clone src dst &&
#                       cd dst &&
#                       actual="z$(git config branch.master.rebase)" &&
#                       test ztrue = $actual
#               )
#

This test is running in /home/gitster/w/rerere, whose .git points at
that directory the fatail: message complains about.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-16 20:39 ` Junio C Hamano
@ 2015-07-16 23:13   ` Duy Nguyen
  2015-07-17  3:11     ` Eric Sunshine
  0 siblings, 1 reply; 11+ messages in thread
From: Duy Nguyen @ 2015-07-16 23:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Eric Sunshine, Git Mailing List

On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Also in a linked checkout of git.git itself, t5601.21 seems to fail
> with:
>
> fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
> not ok 21 - clone respects global branch.autosetuprebase
> #
> #               (
> #                       test_config="$HOME/.gitconfig" &&
> #                       git config -f "$test_config" branch.autosetuprebase remote &&
> #                       rm -fr dst &&
> #                       git clone src dst &&
> #                       cd dst &&
> #                       actual="z$(git config branch.master.rebase)" &&
> #                       test ztrue = $actual
> #               )
> #
>
> This test is running in /home/gitster/w/rerere, whose .git points at
> that directory the fatail: message complains about.

I can't reproduce with either master, next or pu. Seems strange that
git.git info is leaking into this test..
-- 
Duy

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-16 23:13   ` Duy Nguyen
@ 2015-07-17  3:11     ` Eric Sunshine
  0 siblings, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-17  3:11 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List

On Thu, Jul 16, 2015 at 7:13 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Also in a linked checkout of git.git itself, t5601.21 seems to fail
>> with:
>>
>> fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
>> not ok 21 - clone respects global branch.autosetuprebase
>> #
>> #               (
>> #                       test_config="$HOME/.gitconfig" &&
>> #                       git config -f "$test_config" branch.autosetuprebase remote &&
>> #                       rm -fr dst &&
>> #                       git clone src dst &&
>> #                       cd dst &&
>> #                       actual="z$(git config branch.master.rebase)" &&
>> #                       test ztrue = $actual
>> #               )
>> #
>>
>> This test is running in /home/gitster/w/rerere, whose .git points at
>> that directory the fatail: message complains about.
>
> I can't reproduce with either master, next or pu. Seems strange that
> git.git info is leaking into this test..

I also am unable to reproduce the failure...

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
  2015-07-16  5:24 ` Duy Nguyen
  2015-07-16 20:39 ` Junio C Hamano
@ 2015-07-17 12:27 ` Michael J Gruber
  2015-07-17 12:49   ` Duy Nguyen
  2 siblings, 1 reply; 11+ messages in thread
From: Michael J Gruber @ 2015-07-17 12:27 UTC (permalink / raw)
  To: Junio C Hamano, Nguyễn Thái Ngọc Duy; +Cc: Eric Sunshine, git

Two more observations:

$ git worktree add /tmp/gitwt
Enter /tmp/gitwt (identifier gitwt)
Switched to a new branch 'gitwt'

Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
at the original branch.

So either we cd to the new location or quelch these messages or add a
message that we're actually back.

The other:

linked worktrees are prefect for short term tests on detached heads.
Even the manual page advertises detach. But:

$ git worktree add  --detach /tmp/gitwtt
Enter /tmp/gitwtt (identifier gitwtt)
fatal: '--detach' cannot be used with '-b/-B/--orphan'

Maybe it's the auto-naming logic stepping on detached toes ;)

Michael

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-17 12:27 ` Michael J Gruber
@ 2015-07-17 12:49   ` Duy Nguyen
  2015-07-17 15:19     ` Junio C Hamano
  2015-07-17 17:02     ` Eric Sunshine
  0 siblings, 2 replies; 11+ messages in thread
From: Duy Nguyen @ 2015-07-17 12:49 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: Junio C Hamano, Eric Sunshine, Git Mailing List

On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Two more observations:
>
> $ git worktree add /tmp/gitwt
> Enter /tmp/gitwt (identifier gitwt)
> Switched to a new branch 'gitwt'
>
> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
> at the original branch.
>
> So either we cd to the new location or quelch these messages or add a
> message that we're actually back.

s/Enter/Preparing/ ?

> The other:
>
> linked worktrees are prefect for short term tests on detached heads.
> Even the manual page advertises detach. But:
>
> $ git worktree add  --detach /tmp/gitwtt
> Enter /tmp/gitwtt (identifier gitwtt)
> fatal: '--detach' cannot be used with '-b/-B/--orphan'
>
> Maybe it's the auto-naming logic stepping on detached toes ;)

Problem with master (but not with pu) because "-b gitwtt" is
automatically added. I think this is 1eb07d8 (worktree: add:
auto-vivify new branch when <branch> is omitted - 2015-07-06)
forgetting about --detach. Actually it's still a problem with 'pu'
because the branch 'gitwtt' is created unnecessarily.
-- 
Duy

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-17 12:49   ` Duy Nguyen
@ 2015-07-17 15:19     ` Junio C Hamano
  2015-07-17 17:07       ` Eric Sunshine
  2015-07-17 17:02     ` Eric Sunshine
  1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2015-07-17 15:19 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Michael J Gruber, Eric Sunshine, Git Mailing List

Duy Nguyen <pclouds@gmail.com> writes:

> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Two more observations:
>>
>> $ git worktree add /tmp/gitwt
>> Enter /tmp/gitwt (identifier gitwt)
>> Switched to a new branch 'gitwt'
>>
>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
>> at the original branch.
>>
>> So either we cd to the new location or quelch these messages or add a
>> message that we're actually back.
>
> s/Enter/Preparing/ ?

Hmm, do we even need that message?  I assumed it was a leftover
debugging stuff ;-)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-17 12:49   ` Duy Nguyen
  2015-07-17 15:19     ` Junio C Hamano
@ 2015-07-17 17:02     ` Eric Sunshine
  1 sibling, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-17 17:02 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Michael J Gruber, Junio C Hamano, Git Mailing List

On Fri, Jul 17, 2015 at 8:49 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Two more observations:
>>
>> $ git worktree add /tmp/gitwt
>> Enter /tmp/gitwt (identifier gitwt)
>> Switched to a new branch 'gitwt'
>>
>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
>> at the original branch.
>>
>> So either we cd to the new location or quelch these messages or add a
>> message that we're actually back.
>
> s/Enter/Preparing/ ?

Presumably you're using 'master'. The "Switched to a new branch"
message is an artifact of using git-checkout for the back-end
operation, however, what is queued in 'pu' no long uses git-checkout
at all, so that message is gone.

I agree with Duy that s/Enter/Prepare/ would be a good idea. I don't
think we want to drop the message altogether as Junio suggested since
other messages such as "Checking out files:..." and "HEAD is now
at...." follow it, thus "Prepare..." provides context indicating that
those additional messages apply to the new worktree rather than the
current one.

>> The other:
>>
>> linked worktrees are prefect for short term tests on detached heads.
>> Even the manual page advertises detach. But:
>>
>> $ git worktree add  --detach /tmp/gitwtt
>> Enter /tmp/gitwtt (identifier gitwtt)
>> fatal: '--detach' cannot be used with '-b/-B/--orphan'
>>
>> Maybe it's the auto-naming logic stepping on detached toes ;)
>
> Problem with master (but not with pu) because "-b gitwtt" is
> automatically added. I think this is 1eb07d8 (worktree: add:
> auto-vivify new branch when <branch> is omitted - 2015-07-06)
> forgetting about --detach. Actually it's still a problem with 'pu'
> because the branch 'gitwtt' is created unnecessarily.

Yep. Again, that fatal error is an artifact from git-checkout being
used as the back-end on 'master'. What is queued on 'pu' doesn't fail,
however, as Duy notes, the auto-vivication incorrectly kicks in and
creates a new branch unnecessarily. That'll have to be fixed in v3.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: A few "linked checkout" niggles
  2015-07-17 15:19     ` Junio C Hamano
@ 2015-07-17 17:07       ` Eric Sunshine
  0 siblings, 0 replies; 11+ messages in thread
From: Eric Sunshine @ 2015-07-17 17:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Duy Nguyen, Michael J Gruber, Git Mailing List

On Fri, Jul 17, 2015 at 11:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Fri, Jul 17, 2015 at 7:27 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Two more observations:
>>>
>>> $ git worktree add /tmp/gitwt
>>> Enter /tmp/gitwt (identifier gitwt)
>>> Switched to a new branch 'gitwt'
>>>
>>> Now I'm in /tmp/gitwt at branch gitwt. Right? No. I'm in the original wd
>>> at the original branch.
>>>
>>> So either we cd to the new location or quelch these messages or add a
>>> message that we're actually back.
>>
>> s/Enter/Preparing/ ?
>
> Hmm, do we even need that message?  I assumed it was a leftover
> debugging stuff ;-)

It helps give context to messages which follow it, such as "Checking
out files:..." and "HEAD is now at...", letting the user know that
those messages apply to the new worktree rather than the current one.
In this case, s/Enter/Preparing/ makes sense.

("Switched to a new branch..." is gone in 'pu'.)

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2015-07-17 17:07 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-15 23:13 A few "linked checkout" niggles Junio C Hamano
2015-07-16  5:24 ` Duy Nguyen
2015-07-16  5:40   ` Eric Sunshine
2015-07-16 20:39 ` Junio C Hamano
2015-07-16 23:13   ` Duy Nguyen
2015-07-17  3:11     ` Eric Sunshine
2015-07-17 12:27 ` Michael J Gruber
2015-07-17 12:49   ` Duy Nguyen
2015-07-17 15:19     ` Junio C Hamano
2015-07-17 17:07       ` Eric Sunshine
2015-07-17 17:02     ` Eric Sunshine

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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).