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 workflow? > 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? 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
Attachment:
signature.asc
Description: OpenPGP digital signature