Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)

From: Andrew Ardill <andrew.ardill@gmail.com>
Date: Feb 14, 2013, 02:43 UTC
Message-ID: <CAH5451kogwuzOs+BrHksDSdECbHrmW8DwTve0_kKq+-PTx+4bw@mail.gmail.com>
In-Reply-To: <7vpq04b5e2.fsf@alter.siamese.dyndns.org>

On 14 February 2013 02:27, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

>> 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