"W. Trevor King" <wk...@tremily.us> writes:
> 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.
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
