Re: [PATCH 1.8.0] add: make "add -u" update full tree without pathspec

Nguyen Thai Ngoc Duy [off-list ref] writes:

On Mon, Feb 28, 2011 at 2:39 AM, Junio C Hamano [off-list ref] wrote:
...

quoted

What you conceive as a problem is just a reminder that any incompatible
change you plan to add will have pain involved....

No. But I hoped it would help me somehow, or at least remind me to
update git on the machines I touch.

Perhaps the migration plan is not helpful enough?  If that is the case we
would need to rethink it to be even less impactful.

I already do not like the possibility of potential double deprecation
myself, one to flip the default and then possibly another to drop the
support of the traditional behavour, but anything I've seen so far would
hurt the end users more than that plan.

On Mon, Feb 28, 2011 at 1:56 PM, Junio C Hamano [off-list ref] wrote:

Perhaps the migration plan is not helpful enough?  If that is the case we
would need to rethink it to be even less impactful.

But how many people may be impacted this way? If it's few, probably
not worth the headaches. I want to believe the number is few, but I
think anybody who ssh to some machine may have the same problem
because they may not control what's in that machine.

I can only think of another way, ugly though: add a new command name,
say "nad", that goes with new behavior, "add" remains old school. This
way if I mistakenly type 'nad' on unsupported git, it refuses and I'm
safe. Whether the new name is temporary (until the behavior flip in
"add") or permanent is another ugly matter to think about.

Or accept that evolution is painful and go with current plan, which I'm OK too.
-- 
Duy