On Tue, Sep 2, 2008 at 5:07 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "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. 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 -- 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
