Am 05.12.2013 23:06, schrieb Martin Langhoff:
> On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
>> Am 05.12.2013 20:27, schrieb Martin Langhoff:
>>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> 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
Thanks a lot for your feedback!
> - git clone does not clone existing submodules by default. An ideal
> workflow assumes that the user wants a fully usable checkout.
You get that when using "git clone --recurse-submodules", but there
is no configuration option yet to switch that on by default (but we
are planning to add one).
> - git pull does not fetch&update all submodules (assuming a trivial
> "tracking repos" scenario)
Current pull does fetch them (when changes to them are found in the
fetched commits of the superproject), but it does not yet update
them (there is the "recursive update" work in progress to do that).
> - git push does not warn if you forgot to push commits in the submodule
We do have a command line option ("--recurse-submodules=check" is
what you want here), but no configuration option yet.
> 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.
Seems like we already solved some of those, and your feedback shows
me that we are moving in the right direction. I keep a list of open
issues we are aware of at:
https://github.com/jlehmann/git-submod-enhancements/wiki
Feel free to point out missing topics.
> 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.
Good to hear that! Solving them automatically is hard, only fast
forwards are currently resolved without user intervention.
> 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)...
Right you are, we need tutorials for the most prominent use cases.
> 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 ...
That's what we are aiming at :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html