Re: What's cooking in git.git (May 2009, #02; Sun, 17)
- From
Johan Herland <johan@herland.net>
- Date
- May 19, 2009, 07:23 UTC
- Message-ID
- <200905190923.33874.johan@herland.net>
- In-Reply-To
- <7vpre5anaz.fsf@alter.siamese.dyndns.org>
On Tuesday 19 May 2009, Junio C Hamano wrote:
Show 9 quoted lines
> 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.
> And from my point of view, "rebind" (or "autorebind") would be more > appropriate name than "update"
Feel free to fix up my patch with whatever the community finds most appropriate. Personally, I still like "update" better because it determines what "happens" on a git submodule update, but I'm not religious about this.
> (and I would probably set it to "never").
That's perfectly ok. So will I, in most of my repos. But there are cases (e.g. in the workflows at $dayjob) where this feature will be very valuable.
...Johan
-- Johan Herland, <johan@herland.net> www.herland.net