Re: [PATCH] fast-import: add ignore non-existent files option.

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 2, 2008, 02:07 UTC
Message-ID: <7vk5dvs3k8.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <94a0d4530809011625n772fdc58h3ce1c04e79fb116f@mail.gmail.com>

"Felipe Contreras" <felipe.contreras@gmail.com> writes:

Show 13 quoted lines

> On Tue, Sep 2, 2008 at 2:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> This is useful for SCMs that don't have proper changesets in each
>>> revision (monotone).
>>
>> I am still not convinced this is a proper workaround for the issue.  Why
>> shouldn't the feeder of fast-import be able to do this?
>
> If I could get a list of the files that changed on each revision from
> monotone I would, but that's not possible (I've asked in their mailing
> list). Apparently there's a way to feed the right data, but it's
> complicated.

Ok, I did not realize that you are not keeping track of what the parents' trees look like when processing a merge commit.

But it raises a bigger question.  You earlier said:

    In monotone you can have something like:

     A
    / \
    B D
    | |
    C E
    \ /
     F

    If you do a 'delete foo' in B, and a 'delete bar' in F, you will get
    this stored in the merge revision (F):

    old_revision [C]
    delete "foo"
    delete "bar"

    old_revision [E]
    delete "bar"

    All the changes of the merged branches are stored again in the merge revision.

Now, does it talk about C and E because they are immediate parents of B and D, or because they are immediate child of the common ancestor F? I am guessing it is the latter (what I mean is if it still talks aobut C and E if you had more intermediate commits between B and C). What the merge at A records is not relative to B/D but relative to immediate child of the fork point.

If that is the case, ignoring a delete that deletes already deleted path is fine; I think it is the least of your problem. The above description makes me wonder what they say about modification. Do they talk about the same modification that happened between B and C when talking about A? If that is the case, it would be a far larger problem. You cannot just say "ignore any modification recorded in a merge, because they have been already done on the branches being merged (i.e. up to B and up to D)", as A may have to be an evil merge.

I have to wonder if you can "mark" the tree object of C, and when you process merge A, represent A's tree by starting from that marked tree, applying only the description to bring the state of "old_revision [C]" to that of A (delete "foo" and delete "bar" in your illustration), and recording that tree with parents B and D.

Show 6 quoted lines

>>> @@ -1993,8 +1994,15 @@ static void file_change_cr(struct branch *b, int rename)
>>> ...
>>
>> Also what happened to the missing warning() for 'D'elete codepath?
>
> I'm not interested in it.

If I were asking for an unrelated "feature" when you are developing some other feature, it would have been different, but I do not think that is a good answer in this particular case.

Your --tolerant (or --ignore-errors) is about customizing strictness of the error handling, and you know of a case where the error handling is not strict enough in the existing code. In other words, your "not interested" is _not_ saying "It is an unrelated feature that I am not interested in"; it is saying "I am not interested in making my patch self consistent; a half-baked hack that happens to solve my case is good enough for me."