git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com>
Date
Mar 21, 2011, 08:43 UTC
Message-ID
<4D870FAB.4050307@morey-chaisemartin.com>
In-Reply-To
<7vhbb1320t.fsf@alter.siamese.dyndns.org>
On 03/17/2011 09:50 PM, Junio C Hamano wrote:
Show 12 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com> writes:
>>
>>> During a merge with conflict on a submodule, the submodule appears 3
>>> times in git ls-files (stage 1,2,3) which causes the submodule to be
>>> used 3 times in git submodule update or status command.  This patch
>>> filters the results of git ls-files and only shows submodule in stage 0
>>> or 1 thus removing the duplicates.
>> That is a wrong thing to do.  What if both sides added a submodule at the
>> same directory after forked from an ancestor that did not have it?  You
>> will have only stage #2 and stage #3, no?
After a quick check, you're right on that ;)
> It is not very friendly to say a solution is wrong without hinting what
> the right thing to do, so let's try.
Thanks for taking the time to point me in the right direction !
Show 6 quoted lines
> There are 5 callers of module_list; they all read (mode, sha1, stage,
> path) tuple, and most of them care only about path.  As a first level
> approximation, it should be Ok (in the sense that it does not make things
> worse than it currently is) to filter the duplicate paths from module_list
> output.
>
...
>  - 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 agree that the actual behavior of status is definitely wrong and it should be changed. But I think there needs to be a simple way for a user to know whats happening to a conflicted submodule. When merging a file, editing the conflicting area in the code is often enough. For a submodule, I think the user needs an easy access to which branch used what SHA1.

Git submodule status is probably not the right place to do that. git ls-files --stage allows that but it's not part of the standard porcelain commands...

I guess a first step should be to apply the patch you proposed and discuss a later solution to get the submodule SHA1 (well except if there's already one I just don't know about !)
I'll check/test the patch you proposed as soon as possible and repost it if it's allright !
Nicolas Morey-Chaisemartin
Previous: Junio C HamanoNext: Jens Lehmann
Message 4 of 14 in “git-submodule: Remove duplicate entries during merge with conflict”
  1. git-submodule: Remove duplicate entries during merge with conflictNicolas Morey-Chaisemartin, Mar 17, 2011
  2. Junio C HamanoMar 17, 2011
  3. Junio C HamanoMar 17, 2011
  4. Nicolas Morey-ChaisemartinMar 21, 2011
  5. Jens LehmannMar 21, 2011
  6. Jens LehmannMar 21, 2011
  7. Junio C HamanoMar 21, 2011
  8. Nicolas Morey-ChaisemartinMar 21, 2011
  9. Jens LehmannMar 21, 2011
  10. Nicolas Morey-ChaisemartinMar 22, 2011
  11. funeeldyJul 14, 2011
  12. Jens LehmannJul 15, 2011
  13. Marlene CoteJul 15, 2011
  14. Jens LehmannJul 15, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.