"W. Trevor King" [off-list ref] writes:
quoted hunk
@@ -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.
For an end user, running "submodule update" is similar to running
"git pull" in a project that does not use submodules, expressing "I
want to catch up with the work done by others". In a working tree
with local changes, we do allow you to run "git pull" as long as
your local changes do not overlap with the work done by others, and
the result of the pull would look as if you did not have any of the
local changes when you ran "git pull" and then you did the local
changes on top of the state that is up-to-date with their work.
Can't we design "submodule update --checkout" to work in a similar
fashion? The updated superproject may say it wants $oSHA-1 at a
submodule path P, and also its .gitmodules may say that commit is
supposed to be at the tip of branch B=submodule.P.branch in the
submodule repository. You may locally have advanced that branch in
your submodule repository in the meantime to point at $ySHA-1 while
others worked in the superproject and the submodule, and the
difference $oSHA-1...$ySHA-1 can be considered as the local change
made by you from the perspective of the superproject.
Without thinking things through, if $ySHA-1 matches or is a
descendant of $oSHA-1 (assuming that remote-tracking branch
origin/$B in the submodule does point at $oSHA-1 in either case), it
should be safe to do this update.
And in a situation where you cannot do the checkout safely, it is
perfectly fine to say "the submodules X and Y have local changes;
you cannot do 'submodule update' until you upstream them" and fail
the update, just like we fail a 'git pull' saying "you cannot do
pull until you commit them", no?
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"?
On Thu, Jan 16, 2014 at 11:43:44AM -0800, Junio C Hamano wrote:
"W. Trevor King" [off-list ref] writes:
quoted
@@ -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