Re: bug: v2 deletes on incremental fetch [was: Q: V2 format]

[ebiederm@xmission.com (Eric W. Biederman)]

Eric Wong <e@80x24.org> writes:

> "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>> Eric Wong <e@80x24.org> writes:
>> > "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>> >> Then I am going to report a probable bug.  In V2 in public-inbox-index
>> >> I can not find a path from finding a 'd' file and a call to unindex.  V1
>> >> unindexes deleted files.  Rebased heads for purges call unindex.  I
>> >> don't see that for ordinary d files though.
>> >
>> > It shouldn't need to call unindex because they never get indexed
>> > on rebuilds.  V2 indexing walks history backwards (normal "git log"
>> > behavior) so it remembers 'd' paths in the "$D" hash; and skips blobs
>> > as it encounters them.
>> >
>> > v1 needed to unindex because it used "git log --reverse" to walk
>> > forward in history.
>> 
>> This assumes that you see them in the same git pull.  I would think
>> ideally anything that is going to be deleted that quickly you can just
>> skip archiving.
>> 
>> What is the time window of you expecting 'd' messages to appear?
>
> Ah, this is definitely a bug when using incremental fetch + -index.
> Right now, it only warns on unseen entries in $D but won't reach
> beyond the current "git log" window.
>
> I'll take a lookg at it later today/this weekend unless you're
> already working on it.

I am not.

Eric