On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> > Users who are worried about loosing local updates should not be
> > using a checkout-style updates.  If they are using a
> > checkout-style update, and they ask for an update, they're
> > specifically requesting that we blow away their local work and
> > checkout/reset to the new sha1.  Solving update conflicts is the
> > whole point of the non-checkout update modes.
> But checkout is different from reset --hard in that it does not blow
> away local uncommitted changes. Please see below.

Ah, good point.  We should definately die if there are local
uncommitted changes.

> > On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > > Maybe you meant "for checkout I can easily overwrite the local
> > > > changes with the upstream branch", which is what I understand
> > > > checkout to do.
> > > 
> > > But which I find really unfriendly and would not like to see in
> > > a new feature. We should protect the user from loosing any local
> > > changes, not simply throw them away. Recursive update makes sure
> > > it won't overwrite any local modification before it checks out
> > > anything and will abort before doing so (unless forced of
> > > course).
> > 
> > If you want to get rid of checkout-mode updates, I'm fine with
> > that.  However, I don't think it supports use-cases like Heiko's
> > (implied) “I don't care what's happening upstream, I never touch
> > that submodule, just checkout what the superproject maintainer
> > says should be checked out for this branch.  Even if they have
> > been rebasing or whatever” [3].
> I never stated that in that post.

Sorry for misunderstanding.  I think I'm just unclear on your

> The recursive checkout Jens is working on is simply implementing the
> current checkout-mode to the places where the superproject checks
> out its files. That way submodules get checked out when the
> superproject is checked out. If the submodule does not match the
> sha1 registered in the superproject it either stays there (if the
> checkout would not need to update the submodule) or (if checkout
> would need to update) git will not do the checkout and bail out with
> "you have local modifications to ... .

Sounds good to me as far as it goes.  I think it misses the “what
should we do if the gitlinked hashes are different” case, because the
checkout will always leave you with a detached HEAD.

> > > or be asked to resolve the conflict manually when "checkout" is
> > > configured and the branches diverged.
> > 
> > I still think that checkout-mode updates should be destructive.
> > See my paraphrased-version of Heiko's use case above.  How are
> > they going to resolve this manually?  Merge or rebase?  Why
> > weren't they using that update mode in the first place?
> I strongly disagree. They should only be destructive in the sense
> that another commit get checked out but never loose local
> modifications.

I think the key I'm missing is an example workflow where a developer
wants to make local submodule changes, but also wants to use
checkout-mode updates instead of merge/rebase updates.  Can you sketch
one out for me?


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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to