Re: Why does 'submodule add' stage the relevant portions?

Ramkumar Ramachandra [off-list ref] writes:

I'm talking about slightly better defaults at the porcelain level,
at most.

If a change does not even have to break backward compatibilty, that
is a regular enhancement and independent from 2.0, no?

Junio C Hamano wrote:

Ramkumar Ramachandra [off-list ref] writes:

quoted

I'm talking about slightly better defaults at the porcelain level,
at most.

If a change does not even have to break backward compatibilty, that
is a regular enhancement and independent from 2.0, no?

Okay, I'm confused: why are you waiting for 2.0 to change push.default
then?  Isn't that just a "slightly better default at the porcelain
level" and hence a "regular enhancement"?

You're not worried about breaking everyone's muscle memory (is that
not part of backward compatibility)?  So, if I understand correctly, I
can do changes like the following at any time (provided the reviewers
agree that they're sane):
1. Don't make 'git submodule add' stage (which is what this thread was
originally about).
2. Set pull.autostash to true (I still have to re-roll and finish it ofcourse).
3. Set color.ui to auto.
4. Alias 'git status' to 'git status -sb'.
5. Set help.autocorrect to 20.

Ramkumar Ramachandra wrote:

Okay, I'm confused: why are you waiting for 2.0 to change push.default
then?  Isn't that just a "slightly better default at the porcelain
level" and hence a "regular enhancement"?

No.  Among other aspects, "git push" is used heavily by scripts.

Jonathan Nieder wrote:

Ramkumar Ramachandra wrote:

quoted

Okay, I'm confused: why are you waiting for 2.0 to change push.default
then?  Isn't that just a "slightly better default at the porcelain
level" and hence a "regular enhancement"?

No.  Among other aspects, "git push" is used heavily by scripts.

Oh, I see.  I would've expected scripts to specify the refspec
explicitly, instead of relying on a default like this.  Then again, I
saw jc/push-2.0-default-to-simple -- massive changes to scripts in our
own testsuite.

This whole "backward compatibility" thing is not black-or-white: it's
shades of gray.  Can I ask about how "backward incompatible" the other
suggestions I listed were, just so I get a rough idea of your scale?
Junio seems to be very extremist today.

Ramkumar Ramachandra wrote:

This whole "backward compatibility" thing is not black-or-white: it's
shades of gray.  Can I ask about how "backward incompatible" the other
suggestions I listed were, just so I get a rough idea of your scale?

It depends on how important the change is and how painful the proposed
transition is.

Please don't gratuitously break things.  If there is a smooth way to
accomplish the intended effect without much downside, that is
generally preferred, even if it is harder to write the code.

There are no absolutes here.  It is about helping people in the
real world who never asked for such-and-such feature to avoid
suffering real breakage.

Hope that helps,
Jonathan