Andrew Ardill [off-list ref] writes:
On 13 February 2013 11:34, Junio C Hamano [off-list ref] wrote:
quoted
The change could negatively affect people who expect that removing
files that are not used for their purpose (e.g. a large file that is
unnecessary for their build) will _not_ affect what they get from
"git add .";
How big a problem is this?
As you said below, it could be fairly big, if you expect a lot of
people do not use "git add -u".
If we need to support this behaviour than I would suppose a config
option is required. A default config transition path similar to git
push defaults would probably work well, in the case where breaking
these expectations is unacceptable.
We've discussed that before.
http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818
quoted
obviously they must have trained themselves not to do
"git add -u" or "git commit -a".
Many people use git add -p by default, so I would not be surprised
about people not using -u or -a.
On 14 February 2013 02:27, Junio C Hamano [off-list ref] wrote:
quoted
If we need to support this behaviour than I would suppose a config
option is required. A default config transition path similar to git
push defaults would probably work well, in the case where breaking
these expectations is unacceptable.
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?
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', but if they can already grok the
concept of staging then including deletions in that is trivial. If
they don't understand staging then we have a different issue.
- For people who rely heavily on file deletions remaining out of the
index, providing a flag allows them to keep their workflow. No data
would be lost, and most accidents would be easily recoverable.
- For scripts that rely on this behaviour, a flag allows it to be
updated, though it may break in the meantime. (I would presume that
not many of these scripts exist in the first place, but I don't really
know)
Finally, making this change makes sense from a consistency point of
view. For example, we don't track file renames because (and I
paraphrase) we can work that out from the content that is moved.
However if I rename a file and then 'git add .' I see that a new file
is added, not that it has been renamed! Manually adding the deletion
to the index causes git to correctly detect the rename, however this
is unintuitive and not consistent with how git works and is
communicated in general.
Git add is also inconsistent with git add -p (although that might be
due to unclear documentation for -p). When in patch mode, git add will
propose deletions get added to the index as well, not just additions
and modifications.
Regards,
Andrew Ardill