From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Lehmann Subject: Re: [PATCH] submodule: Add --force option for git submodule update Date: Thu, 31 Mar 2011 19:41:32 +0200 Message-ID: <4D94BCCC.7090808@web.de> References: <4D92E225.3040602@morey-chaisemartin.com> <4D93773C.2010807@web.de> <4D937B7E.10808@morey-chaisemartin.com> <4D937F09.10000@web.de> <4D93905E.5030806@morey-chaisemartin.com> <7vd3l8mi3m.fsf@alter.siamese.dyndns.org> <4D93E4F1.70103@morey-chaisemartin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Junio C Hamano , git@vger.kernel.org To: Nicolas Morey-Chaisemartin X-From: git-owner@vger.kernel.org Thu Mar 31 19:42:14 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q5Lsr-0000sC-CT for gcvg-git-2@lo.gmane.org; Thu, 31 Mar 2011 19:42:13 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758668Ab1CaRmG (ORCPT ); Thu, 31 Mar 2011 13:42:06 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:45824 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753627Ab1CaRmF (ORCPT ); Thu, 31 Mar 2011 13:42:05 -0400 Received: from smtp06.web.de ( [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 8605C19B951D9; Thu, 31 Mar 2011 19:41:35 +0200 (CEST) Received: from [93.240.124.73] (helo=[192.168.178.43]) by smtp06.web.de with asmtp (WEB.DE 4.110 #2) id 1Q5LsF-00076i-00; Thu, 31 Mar 2011 19:41:35 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: <4D93E4F1.70103@morey-chaisemartin.com> X-Sender: Jens.Lehmann@web.de X-Provags-ID: V01U2FsdGVkX1/1veSkOKd7r6QP4XQyHYIMrlrwZTi/SwavXIfl w9NJIviwjUlqAeTArAOJqyCjyvV6RDKXKqdio8EX8Ina/BePFO IYQistxv55JFiu84uFSw== Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Am 31.03.2011 04:20, schrieb Nicolas Morey-Chaisemartin: > On 03/30/2011 11:08 PM, Junio C Hamano wrote: >> Shouldn't you be questioning _why_ your users have such changes that >> require them to run "checkout -f" everywhere in the submodule forests and >> still want to run "submodule update" in the first place? If it happens >> very often and your users are constantly discarding what they have half >> accomplished, there is something wrong with the way your project works. > > I did. Thee reason is we commit file generated by compilation. > Whether it's docs, references (for automated integration) or simply result files that take 2 days to build, > we have a strong need to commit generated files. We are in a similar situation at my dayjob, but we handled the issue in a different way. We were reluctant to check in generated files into our repository, so we decided to distribute them via zip files. We have a beefy build machine which builds and tests master over night and if everything went ok it zips the whole work tree including .git directory, build artifacts and submodules into one file. Then each developer just has to unpack this file, fetch from the git server and he is all set. >> If we read your motivation section in your original, >> >> > This implies that to reset a whole git submodule tree, a user has to run >> > first 'git submodule foreach --recursive git checkout -f' to then be >> > able to run git submodule update. >> >> this is about "resetting", i.e. throwing away the work. I think that is a >> sensible thing to do, but it is a very different purpose than "updating >> submodules so that I can work on top of what other people did", which >> would happen a lot more often than that. >> >> Wouldn't it be both safer and easier to understand for the users if this >> "obliterate all my uncommitted work" were a separate subcommand, e.g. "git >> submodule reset --recursive" or something? > > I agree. A git submodule reset command makes a lot of sense. Me too agrees that being able to reset a whole work tree including all submodules recursively makes a lot of sense. But I would not be so happy seeing this functionality being added to the git-submodule.sh script, as I believe it belongs into "git reset", so you'll just have to do a "git reset --hard --recurse-submodules" and you are done. In the branch "git-checkout-recurse-submodules" in my github repo (which is at https://github.com/jlehmann/git-submod-enhancements) you can see a preliminary implementation of that (it works and I use it every day at my job. It has recursion enabled by default at the moment yet still might overwrite local changes even if it shouldn't, so use with care ;-). > But I also still think having a --force option to update does too, in the way Jens proposed it (only on submodule that actually needed a checkout), don't you? Yes, I still think it makes sense to add the "-f" flag to submodule update.