Re: git submodule update --merge

From: Johan Herland <johan@herland.net>
Date: May 25, 2009, 22:10 UTC
Message-ID: <200905260010.37454.johan@herland.net>
In-Reply-To: <7vmy91vxqc.fsf@alter.siamese.dyndns.org>

On Monday 25 May 2009, Junio C Hamano wrote:

Show 16 quoted lines

> Johan Herland <johan@herland.net> writes:
> > I haven't received any replies to my attempt to describe the context in
> > which "git submodule update --merge" is useful. A hint as to whether my
> > argument is valid, or just crap, would be nice.
>
> FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
> convincing to begin with.  Because the configuration variable is about
> "update" action, I agree it makes sense to do
>
> >   submodule.<name>.update = checkout/rebase (checkout if unset)
>
> from the UI standpoint.
>
> I do not know what the sensible repertoire of options nor what the
> default should be, though.  That's up to the submodule using people to
> sort out.

I suggest the default should be whatever "git submodule update" does today, which is what I've called 'checkout' above (i.e. it simply checks out the submodule commit, which naturally detaches the head).

If you prefer, I can split my previous patch in two; one that fixes the config variable, and one that adds "submodule update --merge", so that they can be evaluated separately. Hmm?

Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net