Am 26.12.2013 17:22, schrieb Jonathan Nieder:
> From: Jens Lehmann <jens.lehm...@web.de>
> Date: Wed, 13 Jun 2012 18:50:10 +0200
> Signed-off-by: Jens Lehmann <jens.lehm...@web.de>
> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com>
> This is the patch that actually introduces the --recurse-submodules
> option, which makes the rest work.
> The tests indicate some future directions for improving this, but
> it works reasonably well already. I think I'd be most comfortable
> applying these if they were rearranged a little to the following
> 1. First, introducing the --recurse-submodules option, perhaps
> with no actual effect, with tests that it is parsed correctly,
> the default works, etc.
> 2. Then, adding the desired behaviors one by one with corresponding
> tests (handling submodule modifications, removals, additions).
> 3. Finally, any needed tweaks on top.
> That way, it is easy to play around with early patches without
> worrying about the later ones at first, and the patches are easy
> to review to confirm that they at least don't break anything in
> the --no-recurse-submodules case.
Makes tons of sense.
The only feature I'm aware of that is currently missing is to
read the path <-> name mappings from the correct .gitmodules
blob, which is needed to populate submodules that appear.
> That said, Debian experimental has these applied as is already,
> and there haven't been any complaints yet.
I'm also using this code at $dayjob successfully for quite some
time now. Additionally I also enable unconditional recursive
checkout by putting a "return 1" in the first line of the
submodule_needs_update() function (Which is a hack to emulate
"autoupdate=true" while at the same time pretending to already
having added "--recurse-submodules=config" to all call sites in
git porcelain scripts that call plumbing themselves). Only in a
few corner cases submodules aren't properly updated, but we'll
weed those out while implementing the tests. And we need lots
of those to cover all important combinations ...
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html