Johannes Schindelin [off-list ref] writes:
Do you plan to apply the split-up builtin-add enhancments you did a few
nights ago,...
I have a few updates to that one, I'll be sending them out shortly.
Switching branches between revs that have and do not have submodule at a
given path has always been broken. It is not even a "known breakage",
which is a word used for something that has a sensible design already is
worked out but the implementation does not do so.
If we started the process of diagnosing and fixing these issues earlier,
and had plausible code to address the issue already in 'next' before the
current -rc cycle started, the topic would have been an obvious candidate
for the coming release and I'd further say it would be even worth delaying
the release for a few weeks if it takes more time. But I have to say it
is too late for 1.6.0 now if we are just noticing and starting the
discussion. This comment goes to the issue Pierre raised last night as
well.
Nobody prevents us from starting the process to discuss and prepare to put
something in 'next' for 1.6.1 cycle now, though.
On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Do you plan to apply the split-up builtin-add enhancments you did a few
nights ago,...
I have a few updates to that one, I'll be sending them out shortly.
Switching branches between revs that have and do not have submodule at a
given path has always been broken. It is not even a "known breakage",
which is a word used for something that has a sensible design already is
worked out but the implementation does not do so.
If we started the process of diagnosing and fixing these issues earlier,
and had plausible code to address the issue already in 'next' before the
current -rc cycle started, the topic would have been an obvious candidate
for the coming release and I'd further say it would be even worth delaying
the release for a few weeks if it takes more time. But I have to say it
is too late for 1.6.0 now if we are just noticing and starting the
discussion.
Well given that we now use submodules at work, and that git is
nowadays somewhere in the top 5 of my most consciously (as opposed to
the compiler that I rarely call by hand) used software suites (among my
editor, my MUA, my shell and my tiling WM), I'm very much interested in
tackling some things about what is (not) done with submodules yet.
I sent a mail some time ago about those issues, in short words, those
concern git-checkout, git-reset, git-fetch and git-push for starters.
I'm not sure I can help with the code a lot, but I can for sure provide
a comprehensive list of things I would like the porcelain to do with
submodules if that helps.
This comment goes to the issue Pierre raised last night as well.
You mean the git checkout issue ? Because the issue is twofold, one
there is the missing warnings that users can shoot themselves in the
foot unnoticed, and there is the fact that "git checkout -- $foo" does
not what it should when "$foo" is a valid revision (and *that* is a
really really bad bug, that if I'm correct changing parse_options flags
to KEEP_DASHDASH fixes alright).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org