Re: [RFC v2] submodule: Respect requested branch on all clones

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 7, 2014, 19:21 UTC
Message-ID: <xmqqtxdfd2dj.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140107184659.GF11060@odin.tremily.us>

"W. Trevor King" <wking@tremily.us> writes:

Show 22 quoted lines

> On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
>>     submodule: respect requested branch on all clones
>> 
>>     The previous code only checked out the requested branch in cmd_add
>>     but not in cmd_update; this left the user on a detached HEAD after
>>     an update initially cloned, and subsequent updates using rebase or
>>     merge mode will kept the HEAD detached, unless the user moved to the
>>     desired branch himself.
>> 
>>     Move the branch-checkout logic into module_clone, where it can be
>>     shared by cmd_add and cmd_update.  Also update the initial checkout
>>     command to use 'rebase' to preserve branches setup during
>>     module_clone.  This way, unless the user explicitly asks to work on
>>     a detached HEAD, subsequent updates all happen on the specified
>>     branch, which matches the end-user expectation much better.
>
> This looks reasonable to me, but there are still changes I'd like to
> make for a v3 (e.g. using submodule.<name>.update to trigger local
> branch checkout).  However, I'm currently leaning towards a new 'git
> submodule checkout' command with explicit preferred local submodule
> branches (see [1]).  Maybe this should all wait until Jens rolls out
> his update implementation [2]?

Sounds good.  I'll backburner this one, then.

Show 6 quoted lines

>> Having writing all the above and then looking at the patch again, it
>> is not immediately obvious to me where you use "rebase" when doing
>> the initial checkout, though.
>
> It's used to shift the local branch reference from from the
> (arbitrary) cloned remote branch tip to the explicit submodule $sha1.

The objective is not what I was questioning. In the patch I see

	git checkout -f -q -B "$branch" "origin/$branch"

used in the module_clone (which I think makes sense), and then cmd_update uses "git reset --hard -q" to make sure that the working tree matches the commit $sha1 obtained from the superproject's gitlink (which may make $branch diverged from origin/$branch, but still I think it makes sense).

But there is no 'rebase' I can see in the codepath, which was what I was puzzled about.