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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14 February 2013 02:27, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]