All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Arne Gangstad <finnag@pvv.org>
To: Clemens Buchacher <drizzd@aon.at>
Cc: Junio C Hamano <gitster@pobox.com>,
	Tim Olsen <tim@brooklynpenguin.com>,
	git@vger.kernel.org
Subject: Re: different git-merge behavior with regard to submodules in 1.6.2.4 vs. 1.6.2.1
Date: Wed, 29 Apr 2009 14:15:06 +0200	[thread overview]
Message-ID: <20090429121506.GA1266@pvv.org> (raw)
In-Reply-To: <20090429084209.GA24064@localhost>

On Wed, Apr 29, 2009 at 10:42:09AM +0200, Clemens Buchacher wrote:
[...]
> > git is unfortunately not capable of merging submodules at all, so I
> > added these error messages to give me a hint about what I needed to do
> > in conflicting submodules to get something useful. I have used git a
> > lot more now, so maybe it is time to pick this up again and implement
> > proper recursive sub-module merging.
> 
> Are you sure it's always the right thing to merge conflicting submodule
> versions? The user could easily commit two versions, which you would never
> want merge -- due to changed history, for example. On the other hand, if a
> fast-forward merge is possible I suppose this could be considered a
> non-conflicting change.

I would _like_ git to be able to merge submodules.  However, if we
want to keep limiting sub-modules to only track external independent
3rdparty modules, it isn't so useful I guess. But I also think that
seriously reduces the usefulness of sub-modules.

Maybe a per-submodule flag that indicates whether or not it wants to
be automatically merged from the supermodule? Closely coupled vs
loosely coupled sub-modules.

- Finn Arne

  reply	other threads:[~2009-04-29 12:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 17:36 different git-merge behavior with regard to submodules in 1.6.2.4 vs. 1.6.2.1 Tim Olsen
2009-04-28 18:29 ` Junio C Hamano
2009-04-28 21:12   ` Finn Arne Gangstad
2009-04-29  8:42     ` Clemens Buchacher
2009-04-29 12:15       ` Finn Arne Gangstad [this message]
2009-04-29 18:53       ` [PATCH] Teach gitlinks to combine-diff Junio C Hamano
2009-04-29 20:26         ` [PATCH v2] diff -c -p: do not die on submodules Junio C Hamano
2009-04-29 21:50           ` Alex Riesen
2009-04-29 22:13             ` Johannes Schindelin
2009-04-29 22:19               ` Alex Riesen
2009-04-29 22:39                 ` Johannes Schindelin
2009-04-30  5:47                   ` Alex Riesen
2009-04-30  6:07                     ` Finn Arne Gangstad
2009-04-29 23:09             ` Junio C Hamano
2009-04-29 18:54       ` different git-merge behavior with regard to submodules in 1.6.2.4 vs. 1.6.2.1 Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090429121506.GA1266@pvv.org \
    --to=finnag@pvv.org \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tim@brooklynpenguin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.