Bernhard R. Link venit, vidit, dixit 30.11.2009 15:43: > The itch this idea is supposed to scratch is the problem that a rebase > or a amended commit is no longer a fast-forward, so cannot be easily > pulled. Do you mean pushed? For pull, the state of the branch on the receiving side play a role, of course. > While this is not a problem in most workflows, as one can either merge > or keep everything private and rebase until published, it would be nice > to have a way for cases in between, where both a clean presentable > commit order is to be maintained and people (or yourself from different > repositories) should be able to easily upgrade to newer versions without > an error-prone not-fast-forward. > > My idea to solve this is combining both histories, the rebased/revised > history and the actualy history, marking with some "equal-tree-merge" > the point where they have the same result. > The following mails show some patches to implement this by means of > a merge where all parents have the same tree and some special casing > when encountering such a thing. This has the advantage that older git > version will just see strange merges and may present both histories, > but otherwise just work. Without having the time to go through the detailed setup you described below (sorry), I'm wondering how this differs from what Git calls a trivial merge? Is it merely about asserting that you merge coinciding (heads with) trees? Michael -- 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