"Felipe Contreras" <felipe.contreras@xxxxxxxxx> writes:
> On Tue, Sep 2, 2008 at 2:04 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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.
>>> @@ -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."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
