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

Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules

From
Jens Lehmann <jens.lehmann@web.de>
Date
Sep 13, 2011, 19:13 UTC
Message-ID
<4E6FAB46.30508@web.de>
In-Reply-To
<20110912224934.GA28994@sigill.intra.peff.net>
Am 13.09.2011 00:49, schrieb Jeff King:
Show 17 quoted lines
> So with a set of changes like:
> 
>   [assume submodule at commit A, superproject at commit B]
> 
>   1. Make commit C in submodule repo.
> 
>   2. Make commit D in superproject repo.
> 
>   3. Make commit E in submodule repo.
> 
>   4. Make commit F in superproject repo.
> 
> what does it buy us to find out that the submodule changed from "A" to
> "C"? We can't actually fetch it. We can only fetch the tips of the
> submodule and hope that they include everything we wanted (i.e., both C
> and E; which might not be the case of E rewound and is not a descendant
> of C).

Yes. But working with submodules in my experience only then works well when you never drop a submodule commit recorded in any superproject. At my dayjob we have the convention: You may only record commits that are on the submodule's master - or another never to be rewound integration branch - in the superproject. That gives us all needed commits in a simple fetch.

Show 5 quoted lines
> So since we must accept that we can't necessarily get every intermediate
> step, I wonder if we are simply better off diffing the "before" and
> "after" state of a particular ref, rather than traversing. It's way
> cheaper, and is just as likely to give us the same information (i.e.,
> which submodule paths had changed commits).

The real world use case I have for that is that when a bug introduced by a new submodule commit is detected later on, the superproject's fix records an older submodule commit to remove the problematic change from the superproject. But the submodule's branch isn't rewound (as that is most probably master) but a fix is applied on top of it. Then that one gets tested and - if it was found ok - recorded in the superproject.

Changes like this could be overlooked if you only compare "before" and "after" instead of traversing, leading to not fetching a submodule which does have new commits that are used in the newly fetched superproject's commits. I'd like to have on-demand fetch keep the correct solution of traversing unless we have good reasons against it, especially as teaching checkout & friends to recursively update submodules too depends on all needed commits being present.

Previous: Junio C HamanoNext: Jeff King
Message 10 of 17 in “fetch: avoid quadratic loop checking for updated submodules”
  1. fetch: avoid quadratic loop checking for updated submodulesJeff King, Sep 12, 2011
  2. Junio C HamanoSep 12, 2011
  3. Jens LehmannSep 13, 2011
  4. Jens LehmannSep 14, 2011
  5. Junio C HamanoSep 12, 2011
  6. Jeff KingSep 12, 2011
  7. Junio C HamanoSep 12, 2011
  8. Jeff KingSep 12, 2011
  9. Junio C HamanoSep 12, 2011
  10. Jens LehmannSep 13, 2011
  11. Jeff KingSep 13, 2011
  12. Marc BranchaudSep 14, 2011
  13. Jens LehmannSep 14, 2011
  14. Jeff KingSep 14, 2011
  15. Christian CouderSep 13, 2011
  16. Jeff KingSep 13, 2011
  17. Junio C HamanoSep 13, 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.