Andrew Ardill <andrew.ardill@xxxxxxxxx> writes: >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html