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

[Junio C Hamano <gitster@pobox.com>]

Andrew Ardill <andrew.ardill@gmail.com> writes:

> On 13 February 2013 11:06, Junio C Hamano <gitster@pobox.com> wrote:
>> * jc/add-delete-default (2012-08-13) 1 commit
>>  - git add: notice removal of tracked paths by default
>>
>>  "git add dir/" updated modified files and added new files, but does
>>  not notice removed files, which may be "Huh?" to some users.  They
>>  can of course use "git add -A dir/", but why should they?
>>
>>  Resurrected from graveyard, as I thought it was a worthwhile thing
>>  to do in the longer term.
>>
>>  Stalled mostly due to lack of responses.
>
> What do you need to progress this?
>
> I have been bitten by this before (the 'huh?' reaction) and think the
> previous discussions and patch look reasonable. Does it need testing?

I _think_ the code does what it claims it does; I do not think that
is what is lacking (more testing would not _hurt_, of course).

> Further input??

The updated behaviour is a departure from the traditional norm, and
it would surprise people who do not expect "git add ." to update the
index for removed paths.  For many of them, it may be a pleasant
surprise, but "many" is not "all".

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 ."; obviously they must have trained themselves not to do
"git add -u" or "git commit -a".