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
Junio C Hamano <gitster@pobox.com>
Date
Jan 23, 2009, 20:50 UTC
Message-ID
<7vljt1u4pc.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<8c5c35580901231215q2be36abbla443975cdbb031f0@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
Show 14 quoted lines
> On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
>> Lars Hjemli <hjemli@gmail.com> writes:
>>
>>>>> The plan is to fix these limitations by extending --submodules to allow
>>>>> certain flags/options:
>>>>> a|c|r     include any|checked out|registered submodules
>>>>> H         resolve submodule HEAD to decide which tree to include
>>
>> What do you mean by "decide"?  If HEAD exists (iow, the submodule is
>> checked out), the tree of the commit recorded in the superproject's
>> gitlink entry is included in the result?
>
> No, when H is specified the tree of the currently checked out
> submodule commit would be included.

That makes even less sense. At that point you are mixing a tree with random state from a work tree, and doing so only for submodules. If you want a work tree snapshot, it should be a work tree snapshot, and should not be labelled as a snapshot out of a tree object of the superproject.

Show 7 quoted lines
> I would find the H flag practical for my own usage of submodules. I
> almost never modify the content of the currently checked out submodule
> but I often check out a different HEAD than what is registered in the
> gitlink in the superproject (typically due to testing the superproject
> against different versions of the submodule). And for such a use case,
> being able to create a tarball of my currently checked out state seems
> useful to me.

That would be more like an enhanced version of "git archive" that takes the work tree state, similar to how "git grep" operates on the work tree today.

I agree that would be useful, but I have a moderately strong suspition that your "H" hack that includes the work tree state for checked out submodules into a view that is primarily about the "tree" object in the superproject, without the same "take from the work tree" semantics for paths in the superproject, is more harmful than being helpful to the users in the longer term. It might be simple to implement, but I do not think its semantics can be explained sanely.

Previous: Lars HjemliNext: Lars Hjemli
Message 9 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.