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

Re: Publishing "filtered branch repositories" - workflow / recommendations?

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Dec 5, 2013, 22:06 UTC
Message-ID
<CACPiFCJ3mkOj=E+siideBpPfgS1tSicVQ46KqPK+Tha0DbkZHw@mail.gmail.com>
In-Reply-To
<52A0D9F5.3030101@web.de>
On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
Show 10 quoted lines
> Am 05.12.2013 20:27, schrieb Martin Langhoff:
>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>> Without knowing more I can't think of a reason why submodules should
>>> not suit your use case (but you'd have to script branching and tagging
>>> yourself until these commands learn to recurse into submodules too).
>>
>> The submodules feature is way too fiddly and has abundant gotchas.
>
> Care to explain what bothers you the most? Being one of the people
> improving submodules I'm really interested in hearing more about that.

Very glad to hear submodules is getting TLC! I have other scenarios at $dayjob where I may need submodules, so happy happy.

I may be unaware of recent improvements, here's my (perhaps outdated) list
 - git clone does not clone existing submodules by default. An ideal
workflow assumes that the user wants a fully usable checkout.
 - git pull does not fetch&update all submodules (assuming a trivial
"tracking repos" scenario)
 - git push does not warn if you forgot to push commits in the submodule

there's possibly a few others that I've forgotten. The main issue is that things that are conceptually simple (clone, git pull with no local changes) are very fiddly. Our new developers, testers and support folks hurt themselves with it plenty.

I don't mind complex scenarios being complex to handle. If you hit a nasty merge conflict in your submodule, and that's gnarly to resolve, that's not a showstopper.

While writing this email, I reviewed Documentation/git-submodule.txt in git master, and it does seem to have grown some new options. I wonder if there is a tutorial with an example workflow anywhere showing the current level of usability. My hope is actually for some bits of automagic default behaviors to help things along (rather than new options)...

Early git was very pedantic, and over time it learned some DWIMery. You're giving me hope that similar smarts might have grown in around submodule support ...

cheers,
m
-- 
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
Previous: Jens LehmannNext: Jens Lehmann
Message 6 of 13 in “Publishing "filtered branch repositories" - workflow / recommendations?”
  1. Martin LanghoffDec 4, 2013
  2. Martin LanghoffDec 5, 2013
  3. Jens LehmannDec 5, 2013
  4. Martin LanghoffDec 5, 2013
  5. Jens LehmannDec 5, 2013
  6. Martin LanghoffDec 5, 2013
  7. Jens LehmannDec 6, 2013
  8. Martin LanghoffDec 6, 2013
  9. Heiko VoigtDec 9, 2013
  10. Junio C HamanoDec 9, 2013
  11. Jens LehmannDec 11, 2013
  12. Junio C HamanoDec 11, 2013
  13. Heiko VoigtDec 12, 2013

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.