From: Johan Herland <johan@herland.net>
Date: Tue, 19 May 2009 07:23:33 GMT
Subject: Re: What's cooking in git.git (May 2009, #02; Sun, 17)
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:
> 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