Re: [PATCH] submodule: Respect reqested branch on all clones

From: W. Trevor King <wking@tremily.us>
Date: Jan 5, 2014, 01:08 UTC
Message-ID: <20140105010859.GD3156@odin.tremily.us>
In-Reply-To: <20140105003922.GA21772@sandbox-ub>

On Sun, Jan 05, 2014 at 01:39:22AM +0100, Heiko Voigt wrote:

Show 19 quoted lines

> On Sat, Jan 04, 2014 at 02:54:01PM -0800, W. Trevor King wrote:
> > On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote:
> > > On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote:
> > > > @@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
> > > >  			case ";$cloned_modules;" in
> > > >  			*";$name;"*)
> > > >  				# then there is no local change to integrate
> > > > -				update_module= ;;
> > > > +				if test -n "$branch"; then
> > > > +					update_module="!git reset --hard -q"
> > > 
> > > Does that not put the user in danger of loosing changes?
> > 
> > No, because this is only happens for just-cloned modules.  The user
> > hasn't had time to make local changes yet.
> 
> Ah ok I see. But why the reset then? Doesn't the earlier git
> checkout in your patch take care of checking out the branch and thus
> update to the right revision?

The reset avoids a detached HEAD. With an empty $update_module, the following case block will setup:

  command="git checkout $subforce -q"

which is later called with:

  $command "$sha1"

That's going to give you a detached HEAD.  The new code sets up:

  command="git reset --hard -q"

which will keep you on the branch checked out in module_clone().

Show 30 quoted lines

> > > If submodule.<name>.branch is configured:
> > > 
> > > 	git submodule update
> > > 
> > > will checkout the configured branch instead of the sha1?
> > 
> > The use case described by Francesco, a submodule maintainer Alice
> > sets up the submodule, which downstream developer Bob want to
> > checkout to a branch.  I think that matching the exact commit
> > specified by Alice in Bob's checkout is important, even if the
> > upstream developer Charlie has advanced the referenced branch in
> > the meantime.  Shifting the referenced submodule commit should be
> > an explicit decision made by Alice, not a clone-time accident for
> > Bob.
> 
> But from what I understand of this part of Francesco's use-case
> description:
> 
> > # Developer
> > $ git pull
> > $ git submodule init
> > $ git submodule update --remote
> > $ cd <path>
> > $ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
> 
> Is that he wants to allow the developer to switch to following a
> branch instead of an exact sha1 while some extension in the common
> module is still under development. That makes it easier to develop
> in parallel in the submodule and the superproject because you do not
> need to update the sha1 all the time.

I'll wait for Francesco to clarify his use case. All my patch does is replace the manual:

  $ cd <path>
  $ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch

with an automatic (on update):

  $ branch="$(git config -f .gitmodules submodule.${name}.branch)";
  $ cd "$path"
  $ git checkout -f -q -B "$branch" "origin/$branch"
  $ git reset --hard -q "$sha"

when submodule.<name>.branch is configured. Whether that last bit is desirable or not is debatable. If you *do* want to float the submodule past the commit blessed by Alice, it's easy to add a manual:

  $ git submodule update --remote --rebase "$path"

If we drop the trailing reset (to float the checkout), it's harder to rewind to the commit blessed by Alice, because distinguising between:

a) locally added stuff that we want to merge/rebase onto Alice's $sha,
   and
b) advancements from the automatic float that we *don't* want to
   merge/rebase onto Alice's $sha.

is difficult/impossible. If you use the --checkout strategy (there are no local commits), you can use:

  $ git submodule update --checkout "$path"

but you'd still need to update the branch references to point to the that particular commit.

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