Andrew Ardill [off-list ref] writes:
quoted
We've discussed that before.
http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818
Something that I couldn't find discussed was the option of, rather
than providing a config to 'turn it off', inverting the current
default/flags combo.
That is, currently git add defaults to not staging file deletions, and
we provide command line flags to include them. The consensus in the
thread is that it is better to stage them by default; it seems
reasonable to me that if we stage deletions by default we should
provide flags to _not_ stage them. If that was the entirety of the
change, would your position from that thread, "if we need this
optional, then it is not worth doing this", still hold?
If that is the change we are going to make, and if you can guarantee
that nobody who is used to the historical behaviour will complain,
then I am fine with it, but I think the latter part of the condition
will not hold.
Some people would be adversely affected by this change, but any
objections I can come up with are not game stoppers.
- It is possible newcomers might stumble at deleted files being staged
for commit by a command called 'add',...
New people are fair game; we haven't trained them with the
"inconsistent" behaviour, and the default being different from
historical behaviour will not affect them adversely.
- For people who rely heavily on file deletions remaining out of the
index, providing a flag allows them to keep their workflow.
Allowing to do the things they used to be able to do is a bare
minimum. You are still forcing them to do things differently.
- For scripts that rely on this behaviour, a flag allows it to be
updated, though it may break in the meantime.
Likewise.
Finally, making this change makes sense from a consistency point of
view.
That is a given. Otherwise we wouldn't be even discussing this.
On 14 February 2013 15:36, Junio C Hamano [off-list ref] wrote:
quoted
That is, currently git add defaults to not staging file deletions, and
we provide command line flags to include them. The consensus in the
thread is that it is better to stage them by default; it seems
reasonable to me that if we stage deletions by default we should
provide flags to _not_ stage them. If that was the entirety of the
change, would your position from that thread, "if we need this
optional, then it is not worth doing this", still hold?
If that is the change we are going to make, and if you can guarantee
that nobody who is used to the historical behaviour will complain,
then I am fine with it, but I think the latter part of the condition
will not hold.
Does the impossibility of asserting that no-one will complain put this
in the 'too hard' bucket?
quoted
Some people would be adversely affected by this change, but any
objections I can come up with are not game stoppers.
- It is possible newcomers might stumble at deleted files being staged
for commit by a command called 'add',...
New people are fair game; we haven't trained them with the
"inconsistent" behaviour, and the default being different from
historical behaviour will not affect them adversely.
quoted
- For people who rely heavily on file deletions remaining out of the
index, providing a flag allows them to keep their workflow.
Allowing to do the things they used to be able to do is a bare
minimum. You are still forcing them to do things differently.
The implication here is that a relatively small number of people will
be inconvenienced by needing to specify extra flags/set up an alias.
Compare this to the many for whom the expected behaviour is now
default, and we have a net win.
quoted
Finally, making this change makes sense from a consistency point of
view.
That is a given. Otherwise we wouldn't be even discussing this.
Obviously I agree. I was actually bringing up a point about patch mode
and it got incorporated into the bigger picture; patch mode includes
deletions by default and I don't even know if you can turn that
behaviour off. So, when we talk about git add -u and git add -A, we
should also mention git add -p.
Regards,
Andrew Ardill