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

["Felipe Contreras" <felipe.contreras@gmail.com>]

On Tue, Sep 2, 2008 at 5:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> 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.

Er, no it's the other way around. A is the original child, F is the
merge. I thought it was evident because of the alphabetical ordering.

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

I'm not sure I understand correctly, but anyway, how would you propose
to "mark" the tree objects?

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

Hmm, ok.

-- 
Felipe Contreras