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

Re: RFC: Making submodules "track" branches

From
Marc Branchaud <marcnarc@xiplink.com>
Date
Jun 9, 2010, 15:36 UTC
Message-ID
<4C0FB50F.3020403@xiplink.com>
In-Reply-To
<4C0F3FA9.7000800@web.de>
On 10-06-09 03:15 AM, Jens Lehmann wrote:
Show 16 quoted lines
> Am 09.06.2010 01:09, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>
>>> Don't record a commit in the first place, following a branch is not bound
>>> to a special commit, so pretending to do that might do more harm than good.
>>> Just putting the 0-hash there might be the solution.
>>
>> Ugh.  Even though I understand that in some scenarios you would want to
>> say "I don't care what commit is used for this submodule---just use the
>> tip of the branch 'fred'", I don't think you want to use 0{40} in the
>> superproject.  I think it would be Ok to add such a note to .gitmodules in
>> the superproject, but I also think we should still record which _exact_
>> commit was used to test and validate such a commit in the superproject
>> when it was made.
> 
> I think we are in violent agreement here.
I too am in this camp.
If a submodule is tracking the tip of a branch, I think it's vital that
checking out the superproject's HEAD@{3 months ago} gives you the submodule
as it was in the superproject 3 months ago.  Back then, it may have been
tracking a different branch.  It may not have been tracking a branch at all.
 It may have been using a completely different repository altogether.

It's hard for me to see the utility of having the submodule reflect the tip-of-some-branch-as-of-today when I'm looking at 3-month-old code in the superproject.

AFAICT, Ævar's original proposal does the right thing here, because a submodule tracking a branch would look dirty in the superproject if the branch's HEAD doesn't match the commit ID recorded in the superproject. So "submodule update" would restore the submodule's state to what the superproject says it should be.

I don't think I mind dirty branch-tracking submodules, but folks seem to find it distasteful. However, I believe all the proposals made so far to address it break what I call the superproject's "historical consistency."

I wish I could come up with some way to reconcile clean branch-tracking submodules with historical consistency, but alas my imagination is so far too limited. :(

		M.
Previous: Jens LehmannNext: Ævar Arnfjörð Bjarmason
Message 18 of 21 in “RFC: Making submodules "track" branches”
  1. Ævar Arnfjörð BjarmasonJun 7, 2010
  2. Johan HerlandJun 8, 2010
  3. Marc BranchaudJun 8, 2010
  4. Ævar Arnfjörð BjarmasonJun 8, 2010
  5. Marc BranchaudJun 8, 2010
  6. Ævar Arnfjörð BjarmasonJun 8, 2010
  7. Marc BranchaudJun 9, 2010
  8. Jens LehmannJun 8, 2010
  9. Johan HerlandJun 8, 2010
  10. Jens LehmannJun 9, 2010
  11. Johan HerlandJun 9, 2010
  12. Steven MichalskeJun 9, 2010
  13. Johan HerlandJun 9, 2010
  14. Junio C HamanoJun 8, 2010
  15. Ævar Arnfjörð BjarmasonJun 8, 2010
  16. Jens LehmannJun 9, 2010
  17. Jens LehmannJun 9, 2010
  18. Marc BranchaudJun 9, 2010
  19. Ævar Arnfjörð BjarmasonJun 9, 2010
  20. nottrobinNov 20, 2012
  21. W. Trevor KingNov 20, 2012

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.