Re: [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone

From: W. Trevor King <wking@tremily.us>
Date: Jan 16, 2014, 21:12 UTC
Message-ID: <20140116211234.GZ2647@odin.tremily.us>
In-Reply-To: <xmqqiotjzp8v.fsf@gitster.dls.corp.google.com>

On Thu, Jan 16, 2014 at 11:43:44AM -0800, Junio C Hamano wrote:

Show 30 quoted lines

> "W. Trevor King" <wking@tremily.us> writes:
> 
> > @@ -817,11 +831,15 @@ cmd_update()
> >  
> >  		displaypath=$(relative_path "$prefix$sm_path")
> >  
> > -		if test "$update_module" = "none"
> > -		then
> > +		case "$update_module" in
> > +		none)
> >  			echo "Skipping submodule '$displaypath'"
> >  			continue
> > -		fi
> > +			;;
> > +		checkout)
> > +			local_branch=""
> > +			;;
> > +		esac
> 
> I wonder if there is a way to avoid detaching (and you may need to
> update the coddpath that resets the submodule to the commit
> specified by the superproject tree) when it is safe to do so.
>
> …
> 
> Perhaps that kind of "'git submodule update' is parallel to 'git
> pull' in the project without submodules" is better done with other
> update modes like --rebase or --merge.  If so, how should we explain
> what 'submodule update --checkout' is to the end users?  Is it
> supposed to be like "git fetch && git checkout origin/master"?

It sounds like you're looking for:

  submodule.<name>.update = !git merge --ff-only

That's fine for folks who want that sort of advancement, but I think there will also be blind updaters who just want the gitlinked commit, and don't care if that blows away local work, because they never work locally in the submodule. They'll still prefer the current checkout-mode with it's clobbering.

I think the best way to explain this to users is to have 'git checkout' (with an optional '--recurse-submdules' trial period) checkout the gitlinked commit automatically. Then there is never local submodule work that is not committed or stashed in the superproject (or stashed on some out-of-the-way branch in the submodule). Currently we have:

  1. Checkout a superproject branch and currently gitlinked submodule.
  2. Do local work on the submodule.
  3. Alter the superproject and its gitlinks.
  4. 'git submodule update' to integrate your work from 2 with the
     changes from 3 and checkout the appropriate submodule commit.

I think it would make more sense to:

  1. Checkout a superproject branch and currently gitlinked submodule.
  2. Do local work on the submodule.
  3. Commit your new gitlink to the superproject (or stash it, or put
     it on a temporary submodule branch and reset the submodule HEAD
     to the old value).
  4. Alter the superproject and its gitlinks, using the existing logic
     to integrate conflicts.  Automatically checkout the appropriate
     submodule commit (as the appropriate submodule branch).

That shifts “dealing with local submodule changes” from an integration-time issue (I just called submodule update, what changes are local?) to a pre-checkout-time issue (I've got a dirty submodule (it's HEAD is not the gitlinked commit, all of these changes are local). I think that's a lot easier to wrap your head around.

This series is a stop-gap to avoid detached HEADs after cloning, non-checkout updates, while we hash out the real solution ;).

Cheers, Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy