Re: [PATCH 1/5] port --ignore-unmatch to "git add"
Quoting "Luke-Jr" <luke@dashjr.org>
Show 23 quoted lines
> On Friday 14 August 2009 02:52:33 pm Junio C Hamano wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>> > Junio C Hamano wrote:
>> >> Chould you refresh my memory a bit?
>> >>
>> >> In what circumstance is "rm --ignore-unmatch" useful to begin with?
>> >
>> > Not sure about add --ignore-unmatch myself, but there's even an
>> > example of rm --ignore-unmatch in man git-filter-branch, along the
>> > lines of
>> >
>> > git filter-branch --index-filter '
>> > rm --ignore-unmach some_file_that_shouldnt_be_in_history
>> > ' -- --all
>>
>> Ah, that makes sense. I am not sure about "add --ignore-unmatch" myself
>> either, and an example similar to the above filter-branch would not apply
>> very easily (i.e. "add a file that should have been in history" would not
>> need --ignore-unmatch).
>
> The purpose of "add --ignore-unmatch" is to ignore race conditions where one
> of the files to be added has been deleted after git is executed, but before
> git scans it.
First of all, it should have been mentioned as part of your proposed commit log message.
Second of all, if a race condition makes an "add" fail, isn't it a good thing? If your "add" ignored such a failure, you'd be recording an inconsistent or incomplete state.
IMHO, fixing your racy script is a much cleaner solution to your problem than forcing "git add" to ignore errors.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Nanako Shiraishi <nanako3@lavabit.com>