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

"Felipe Contreras" [off-list ref] writes:

On Tue, Sep 2, 2008 at 2:04 AM, Junio C Hamano [off-list ref] wrote:

quoted

Felipe Contreras [off-list ref] writes:

quoted

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.

quoted

quoted

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

On Tue, Sep 2, 2008 at 5:07 AM, Junio C Hamano [off-list ref] wrote:

"Felipe Contreras" [off-list ref] writes:

quoted

On Tue, Sep 2, 2008 at 2:04 AM, Junio C Hamano [off-list ref] wrote:

quoted

Felipe Contreras [off-list ref] writes:

quoted

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?

quoted

quoted

quoted

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