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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2013, 00:34 UTC
Message-ID: <7vsj51caqb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAH5451nPKq8DKwo+Bkxh08N-wqrYCY4BihbvaE14z5iGVA1iZw@mail.gmail.com>

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

Show 17 quoted lines

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