Re: What's cooking in git.git (May 2009, #02; Sun, 17)
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- May 19, 2009, 08:17 UTC
- Message-ID
- <alpine.DEB.1.00.0905191015560.26154@pacific.mpi-cbg.de>
- In-Reply-To
- <200905190923.33874.johan@herland.net>
Hi,
On Tue, 19 May 2009, Johan Herland wrote:
Show 15 quoted lines
> On Tuesday 19 May 2009, Junio C Hamano wrote: > > Johan Herland <johan@herland.net> writes: > > > After some thinking, I don't like my original name > > > submodule.<name>.resolve, since ".resolve" sounds more like a merge > > > strategy or conflict resolution method, than a "how to deal with > > > submodule update" choice. I propose submodule.<name>.update instead. > > > > Sounds like a plan, even though I do not necessarily agree with the > > idea of automatically rebinding what is at the submodule path every > > time you update the toplevel project tree. > > I agree that in many workflows this does not make sense, but I believe > that (as with 'git submodule update --rebase') there are some cases > where it does make sense, and I see no reason to support one, but not > the other.
We have a _lot_ of obscure things that are not supported by core Git, but are _very_ easy to add as _tiny_ add-on scripts by the user, without the need for "official" feature support.
Just like this one, Dscho