{"thread":{"id":"10040","subject":"Re: History over-simplification","startedAt":"2007-09-27T04:56:40Z","lastAt":"2007-09-27T05:34:29Z","messageCount":2,"participants":["linux@horizon.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54133","messageId":"20070927045640.31040.qmail@science.horizon.com","threadId":"10040","inReplyTo":null,"subject":"Re: History over-simplification","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-09-27T04:56:40Z","receivedAt":"2007-09-27T04:56:40Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":">>  b) The resulting path matches one of the parents but not one of\n>>     the others.  In such a case the merge should still be output if\n>>     a 3-way read-tree would not have chosen this result by default.\n\n> I am not sure (b) is useful in general.  Merging two branches\n> that fix the same issue but in different ways (think: 'maint'\n> and 'master' have different infrastructure and a fix initially\n> made on 'master' was backported to 'maint', and then later\n> 'maint' needed to be merged to 'master' to carry forward other\n> fixes) is a norm, and in such cases taking the version from the\n> merged-to branch is almost always what happens.\n>\n> Also it sounds to me by \"if read-tree would not have chosen this\n> result by default\" you mean this feature would not just need to\n> run merge-base but also recursive merge-base synthesis, and also\n> recreate the structural merge (aka \"rename detection\") there as\n> well.  Even if (b) is useful, it sounds like a very expensive\n> option, and the current merge-recursive code is structured in\n> such a way to be easily reused for this purpose.\n\nThese seem like roundabout ways of expressing the requirement.\nThe desired rule is \"no silent changes in the simplified history\".\nE.g. if the revision history of a particular file is:\n\n      +-C-+\n     /     \\\nA---B       B---D\n     \\     /\n      +-B-+\n\nThen the normal code will notice that there are no changes on the\nlower branch, prune the merge entirely, and simplify to A---B---C---D.\nThis is, however, misleading; the true history is A---B---C---B---D.\nA merge must be shown unless it matches a *non-eliminated* ancestor.\n\nThe point is that this isn't expressed in terms of what merge-base would\ndo, but in terms of what the path limiter is in the process of doing.\n\n\nNow, I haven't dived into the Deep Magic of revision.c to figure out\nwhere to put this into the code, unfortunately.\n\n\nAnother way to say it is that the desired simplified history\nis achieved when you have exhausted the following two rules:\n- You may delete any revision which has only one ancestor and\n  is identical (after path-limiting) to that ancestor.\n  (Descendants are implicitly linked to that ancestor.)\n- You may delete any ancestor link A---B if there is an\n  alternative directed path between A and B.\n  (Fast-forward rule.)\nGiven unlabeled ancestor links, there is a unique fixed point.\n\nThe current code is willing to delete a revision that is\nidentical to *any* ancestor, even deleted ones.\n"},{"id":"54134","messageId":"7v4phgzn6i.fsf@gitster.siamese.dyndns.org","threadId":"10040","inReplyTo":"20070927045640.31040.qmail@science.horizon.com","subject":"Re: History over-simplification","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-27T05:34:29Z","receivedAt":"2007-09-27T05:34:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> These seem like roundabout ways of expressing the requirement.\n> The desired rule is \"no silent changes in the simplified history\".\n> E.g. if the revision history of a particular file is:\n>\n>       +-C-+\n>      /     \\\n> A---B       B---D\n>      \\     /\n>       +-B-+\n>\n> Then the normal code will notice that there are no changes on the\n> lower branch, prune the merge entirely, and simplify to A---B---C---D.\n> This is, however, misleading; the true history is A---B---C---B---D.\n\nDo you denote the same content with the same letter in the\nabove?\n\nIf so, wouldn't the simplified history be just A-B-D?\n"}]}