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

Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 24, 2009, 13:51 UTC
Message-ID
<alpine.DEB.1.00.0901241443270.13232@racer>
In-Reply-To
<8c5c35580901240044y452b465fj94df82fc2b8f7ee9@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Lars Hjemli wrote:
Show 8 quoted lines
> On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> >  in all of Git, we try to assume that only reachable objects are valid 
> >  objects.
> 
> I don't think this is true (most git commands accepts their arguments
> as valid objects without verifying if they are reachable from a ref).

The fact that a user can ask for some object directly, and that we do not try to validate it in that case has nothing to do with said assumption.

If something is pushed to a remote, and the connection fails, some commit could be pushed already, but some of its reachable objects lacking.

The user on the remote side can still try to salvage parts by accessing the objects directly, by their name.

But the only guarantee that the objects are reachable is to start from a ref.

Concretely, if your patch is applied as-is, such a half-pushed state could affect git-archive in a nasty way: even if the user started from a ref, there could be missing objects!

> Do you feel it is necessary to perform a reachability check of the 
> gitlink'd commit before traversing into a submodule tree?
No.  Because HEAD is a ref, too.

Now, there is still a problem when your submodule is missing the objects for the commit your superproject is referring to.

IMO that is a serious issue, as it just asks for confused users.
Show 7 quoted lines
> > - presence of a specific commit in the supermodule is a _lousy_ 
> >   indicator that the user wants to include that submodule in the 
> >   archive.
> 
> This is the issue I tried to address with my
> `--submodules=[a|c|r][g:<name>]` proposal in the commit message for
> this patch.
Nope, doing this "in the future" does not please me one bit.

Besides, I find the semantics, uhm, "interesting". (The other word would be "unintuitive". Why do you have to be so cryptic that I have to read the proposal to understand what the heck "c" is about?)

Ciao, Dscho

Previous: Lars HjemliNext: Lars Hjemli
Message 13 of 19 in “Add support for `git archive --submodules`”
  1. 0/3 Add support for `git archive --submodules`Lars Hjemli, Jan 22, 2009
  2. 1/3 tree.c: teach read_tree_recursive how to traverse gitlink entriesLars Hjemli, Jan 22, 2009
  3. 2/3 sha1_file: prepare for adding alternates on demandLars Hjemli, Jan 22, 2009
  4. 3/3 archive.c: add basic support for submodulesLars Hjemli, Jan 22, 2009
  5. Johannes SchindelinJan 22, 2009
  6. Lars HjemliJan 23, 2009
  7. Junio C HamanoJan 23, 2009
  8. Lars HjemliJan 23, 2009
  9. Junio C HamanoJan 23, 2009
  10. Lars HjemliJan 23, 2009
  11. Johannes SchindelinJan 23, 2009
  12. Lars HjemliJan 24, 2009
  13. Johannes SchindelinJan 24, 2009
  14. Lars HjemliJan 24, 2009
  15. Johannes SchindelinJan 24, 2009
  16. Lars HjemliJan 24, 2009
  17. Johannes SchindelinJan 22, 2009
  18. Lars HjemliJan 23, 2009
  19. Johannes SchindelinJan 23, 2009

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.