Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 21.03.2011 22:34, schrieb Nicolas Morey-Chaisemartin:
> On 21/03/2011 21:29, Jens Lehmann wrote:
>>
>>>  - Update should refrain from touching the submodule itself. It may want
>>>    to recurse into the submodule of the unmerged one, but people involved
>>>    in submodule work should think things through;
>>
>> I don't think recursing would make any sense here. It might be unknown
>> to what commit the sub-submodules should be updated to if their commits
>> differ in the unmerged branches. So I'd vote for not recursing at all in
>> this case (which is what your patch does).
>>
> 
> After a bit of thinking about the way we use git at my company, there is something that could be done here. It may be completely useless for most people (or maybe even stupid and feel free to enlighten me!)
> We work with continuous integration on two level of git (1 integration which only has submodules and lots of source repositories).
> The usual thing when a user want to push its diff is:
> - commit in the submodules on his branch
> - Update the submodules refs in the integration repo on his branch
> - Pull master 
> - See there are conflicts
> - Blindly pull master in all the conflicted submodules. Push the merge
> - Commit in the integration repo and pray it works !
> 
> Although in the scheme git submodule update by itself does not make much sense. What people actually do is pretty much a git submodule update --merge of the conflicting SHA1 for each submodule.
> 
> For the moment we used either ruby scripts or a list of commands that users blindly follows without understanding much of it, and seeing something like that (there's probably a nicest way to do it) in git would be great.

Hmm, I'm not sure if I fully understand your use case. Maybe being able
to tell pull to run a "git merge <sha1-from-upstream>" in submodules
where the superproject's merge produced conflicts would help you?

>>>  - Status does not have anything to report for an unmerged submodule. It
>>>    may want to recurse into the submodule of the unmerged one, but people
>>>    involved in submodule work should think things through; and
>>
>> I do think status does have something to report here. First its job is to
>> list all submodules, so currently unmerged submodules should show up too,
>> and then it tells the user something about the state of the submodule. So
>> I would propose to print a line for the submodule starting with a special
>> character that tells the user the submodule has a merge conflict. We
>> could e.g. use a '*' here (additionally to '-' for uninitialized and '+'
>> for those submodules where the HEAD differs from the commit recorded in
>> the superproject).
>>
> Being a big user of __git_ps1, my brain now considers '*' has uncached diff and '+' has cached diff. I'd rather have something as 'U' that stands outs.

That is a good argument against '*'. I don't have strong feelings about
that, I just came up with '*' because "git submodule status" already uses
'-' and '+' in it's output. But anyways, 'U' is fine for me too.