Re: [PATCH] submodule: Add --force option for git submodule update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/30/2011 09:05 PM, Jens Lehmann wrote:
>> I know it is very intrusive. The main reason for that is I wanted the -f option to always behave the same (meaning throw away changes),
>> whether the submodule is already on the right commit or not.
> 
> Hmm, I don't know if that is a good thing to do. People are used to
> "git submodule update" to only touch those submodule where the HEAD
> differs from the commit recorded in the superproject (And I often
> find myself using "-f" if the command didn't succeed without it).
> But when using "-f" touches other submodules than not using it the
> user might experience a rather unpleasant surprise, I'm not sure we
> want to go that way.
> 

Well I was'nt sure about it either.
The idea for me was to be able to put the repo and submodules in the cloned state (except for ignored files)
In the current version the right thing to do is a bit of a mess:
$ git submodule foreach --recursive 'git checkout -f HEAD'
$ git submodule foreach --recursive 'git clean -f' # An untracked file on HEAD may be overwrittent by the new HEAD so checkout may fail if you don't do that
$ git submodule update --recursive

Hopefully with --force we can simplify to:
$ git submodule foreach --recursive 'git checkout -f HEAD'
$ git submodule update --recursive --force

However the first step is not that trivial for most people (I sadly have too many first hand examples with my git users).
If the --force option only works on submodule where HEAD differs from the reference, the first step will still be necessary !
I find this a bit redundant.

Maybe another way would be to add another option.
Keep the --force as you proposed. And add a --all option of some sort that let the user decides if he wants to hit all the submodules or not.
This way we keep the regular behaviour with -f but provide a way to bypass the first step above.

Nicolas Morey-Chaisemartin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]