Re: different git-merge behavior with regard to submodules in 1.6.2.4 vs. 1.6.2.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]