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

Re: [PATCH] submodule: show inconsistent .gitmodules precedence

From
Glen Choo <chooglen@google.com>
Date
Jun 28, 2023, 01:36 UTC
Message-ID
<kl6lsfacqsed.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To
<xmqqo7l0e5x3.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 5 quoted lines
> The last-one-wins sounds like a natural outcome for reusing the
> config reading machinery, and the first-one-wins sounds like a total
> confusion, but we probably should fail any operation before the user
> fixes the .gitmodules by removing all but one path for each
> submodule.

An informal poll amongst Googlers suggests that my team mostly agrees: last-one-wins makes more sense than first-one-wins, but erroring out is the most sensible thing to do.

I'm not sure how reasonable it is to just fail. It makes sense if we were only reading .gitmodules from the working tree (the user can fix that), but we also read .gitmodules from commits, and I don't see (yet) how a user could reasonably recover from that.

Previous: Junio C Hamano
Message 3 of 3 in “submodule: show inconsistent .gitmodules precedence”
  1. submodule: show inconsistent .gitmodules precedenceGlen Choo via GitGitGadget, Jun 27, 2023
  2. Junio C HamanoJun 28, 2023
  3. Glen ChooJun 28, 2023

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.