On Sun, Jan 05, 2014 at 01:39:22AM +0100, Heiko Voigt wrote: > 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().
> > > 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
signature.asc
Description: OpenPGP digital signature
