{"thread":{"id":"30117","subject":"Re: rebase -p loses amended changes","startedAt":"2012-03-31T05:55:22Z","lastAt":"2012-04-10T07:14:22Z","messageCount":18,"participants":["Jon Seymour","Thomas Rast","J Robert Ray","Junio C Hamano","Phil Hord","Johannes Sixt","Martin von Zweigbergk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188233","messageId":"CAH3Anrqorf481jw6GdHqOPg9WC0rD-OraOHZ7twWRF4+oJ9X4A@mail.gmail.com","threadId":"30117","inReplyTo":"592E2EEC-6CBA-48D6-8D44-34A971DD78EC@gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-03-31T05:55:22Z","receivedAt":"2012-03-31T05:55:22Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"| My apologies to Thomas and Robert who also received my previous\nattempts to send this to this list which were foiled by my iPad's\ninstance on sending HTML(via two different clients) and the mailing\nlist's (quite understandable) refusal to accept it.\n\nOn Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast wrote:\n> J Robert Ray writes:\n>\n>> If a merge is amended to add changes to a file unaffected by the\n>> merge, these changes are lost after a rebase. Attached is a script to\n>> demonstrate the problem.\n> ...\n\n\n>\n> That's pretty much expected. rebase -p attempts to (conflicts will\n> happen again) replay the merge. I don't think anybody's come up with a\n> clear idea of how to apply the conflicted or evil parts of the merge\n> mechanically.\n>\n\nI wonder if there are any really good justifications for changing the\ncontent, as distinct from the comments of a merge during an amendment?\n\nIf not, perhaps git could be a little bit noisy about the circumstance\nat the point of the --amend commit?\n\njon.\n"},{"id":"188242","messageId":"87fwcpun95.fsf@thomas.inf.ethz.ch","threadId":"30117","inReplyTo":"CAH3Anrqorf481jw6GdHqOPg9WC0rD-OraOHZ7twWRF4+oJ9X4A@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-03-31T09:35:02Z","receivedAt":"2012-03-31T09:35:02Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jon Seymour writes:\n\n> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast wrote:\n>> J Robert Ray writes:\n>>\n>>> If a merge is amended to add changes to a file unaffected by the\n>>> merge, these changes are lost after a rebase. Attached is a script to\n>>> demonstrate the problem.\n>>\n>> That's pretty much expected. rebase -p attempts to (conflicts will\n>> happen again) replay the merge. I don't think anybody's come up with a\n>> clear idea of how to apply the conflicted or evil parts of the merge\n>> mechanically.\n>\n> I wonder if there are any really good justifications for changing the\n> content, as distinct from the comments of a merge during an amendment?\n\nSemantic conflicts do not necessarily show up as\nconflicts-to-be-resolved. The canonical example is when you change the\nsignature of a function on one side of the merge, and introduce new\ncallers on the other side. The merge must then patch all new callers\ntoo.\n\n> If not, perhaps git could be a little bit noisy about the circumstance\n> at the point of the --amend commit?\n\nThat could still be done of course.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"188243","messageId":"CAH3AnrpasFU2bLEZsAXRQu4U+=R_YyW+-yRXDfzy2JQpqf9dNw@mail.gmail.com","threadId":"30117","inReplyTo":"87fwcpun95.fsf@thomas.inf.ethz.ch","subject":"Re: rebase -p loses amended changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-03-31T09:39:05Z","receivedAt":"2012-03-31T09:39:05Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast wrote:\n> Jon Seymour writes:\n>\n>> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast wrote:\n>>\n>> I wonder if there are any really good justifications for changing the\n>> content, as distinct from the comments of a merge during an amendment?\n>\n> Semantic conflicts do not necessarily show up as\n> conflicts-to-be-resolved.  The canonical example is when you change the\n> signature of a function on one side of the merge, and introduce new\n> callers on the other side.  The merge must then patch all new callers\n> too.\n\nFair enough - I was thinking that you could these with a commit after\nthe merge, but I can see that's not the right thing to do, from a\ncorrectness point of view.\n\njon.\n"},{"id":"188427","messageId":"CADb3U=4Y0njLiYC1qrYbdm+h0h8vLh78yfz_u3B6veEqCX0xCQ@mail.gmail.com","threadId":"30117","inReplyTo":"CAH3AnrpasFU2bLEZsAXRQu4U+=R_YyW+-yRXDfzy2JQpqf9dNw@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"J Robert Ray","fromEmail":"jrobertray@gmail.com","sentAt":"2012-04-03T18:55:26Z","receivedAt":"2012-04-03T18:55:26Z","isPatch":false,"sender":{"key":"jrobertray@gmail.com","avatar":null},"body":"On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour wrote:\n> On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast wrote:\n>> Jon Seymour writes:\n>>\n>>> On Sat, Mar 31, 2012 at 9:49 AM, Thomas Rast wrote:\n>>>\n>>> I wonder if there are any really good justifications for changing the\n>>> content, as distinct from the comments of a merge during an amendment?\n>>\n>> Semantic conflicts do not necessarily show up as\n>> conflicts-to-be-resolved.  The canonical example is when you change the\n>> signature of a function on one side of the merge, and introduce new\n>> callers on the other side.  The merge must then patch all new callers\n>> too.\n>\n> Fair enough - I was thinking that you could these with a commit after\n> the merge, but I can see that's not the right thing to do, from a\n> correctness point of view.\n\nI thought there would be more concern about the silent data loss.\nInstead of throwing away the amended changes I would prefer the rebase\nto at least fail, if not have the problem require manual conflict\nresolution.\n\nA warning at the time of the amend could confuse or scare users. But a\nmention of this problem in the rebase docs would help.\n"},{"id":"188440","messageId":"CAH3Anrq_Z0V=DpU1iH-A3F8RFWTG0_C1hEe3iDZYe=AYDTRT3g@mail.gmail.com","threadId":"30117","inReplyTo":"CADb3U=4Y0njLiYC1qrYbdm+h0h8vLh78yfz_u3B6veEqCX0xCQ@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-04-03T21:43:29Z","receivedAt":"2012-04-03T21:43:29Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 4, 2012 at 4:55 AM, J Robert Ray wrote:\n> On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour wrote:\n>> On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast wrote:\n>>> Jon Seymour writes:\norrectness point of view.\n>\n> I thought there would be more concern about the silent data loss.\n> Instead of throwing away the amended changes I would prefer the rebase\n> to at least fail, if not have the problem require manual conflict\n> resolution.\n>\n> A warning at the time of the amend could confuse or scare users. But a\n> mention of this problem in the rebase docs would help.\n\nIt'd be quite expensive to attempt to detect cases where this might be\na problem, but let's articulate, as a thought experiment, what such a\nsolution might look like - I am not suggesting that it is a good idea,\nbut the thought experiment might be illustrative.\n\nSuppose you have a merge of a A and B that produces M, which is then\namended as M'.\n\nDuring rebase, you redo the merge A and B. If there are no conflicts,\nthen compare M with M' to produce D. You now have enough information\nto reproduce the amended commit M' during a rebase (merge Ar and,Br\nthen apply D).\n\nWhat isn't clear to me, in this thought experiment, is how you might\nattempt to solve the case where there were syntactic (as opposed to\nsemantic) conflicts between the merge of A and B originally. You have\nno idea, at that point, how the user originally resolved the conflicts\nto produce M, thus no idea how to calculate D or even if there was a\nnon-trivial D.\n\nIn this circumstance, you stop and warn the user about the merge\nconflict, but you have no good way (??) to warn them about the\npotential loss of the amendment, D, since at this point you have no\nclue whether there was such an amendment and you don't want to worry\nthem about conditions that usually do not occur (amended merges, I\nwould have thought, are quite rare).\n\n??: does git rerere help at all, in this case, I wonder?\n\nCertainly, there is no harm, I think, adding a note to the\ndocumentation of --preserve-merges that states something like:\n\n--preserve-merges does not attempt to preserve the resolution of merge\nconflicts or the amendment of merge commits ???; any histories\ncontaining such changes cannot be reliably recreated by git rebase.\n\n??? - except to the extent allowed by git rerere?\n\njon.\n"},{"id":"188443","messageId":"7vwr5wbhk3.fsf@alter.siamese.dyndns.org","threadId":"30117","inReplyTo":"CAH3Anrq_Z0V=DpU1iH-A3F8RFWTG0_C1hEe3iDZYe=AYDTRT3g@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-03T22:02:04Z","receivedAt":"2012-04-03T22:02:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> It'd be quite expensive to attempt to detect cases where this might be\n> a problem, but let's articulate, as a thought experiment, what such a\n> solution might look like - I am not suggesting that it is a good idea,\n> but the thought experiment might be illustrative.\n>\n> Suppose you have a merge of a A and B that produces M, which is then\n> amended as M'.\n>\n> During rebase, you redo the merge A and B. If there are no conflicts,\n> then compare M with M' to produce D. You now have enough information\n> to reproduce the amended commit M' during a rebase (merge Ar and,Br\n> then apply D).\n\nNot necessarily. You realized yourself a half of it.\n\n> What isn't clear to me, in this thought experiment, is how you might\n> attempt to solve the case where there were syntactic (as opposed to\n> semantic) conflicts between the merge of A and B originally. You have\n> no idea, at that point, how the user originally resolved the conflicts\n> to produce M, thus no idea how to calculate D or even if there was a\n> non-trivial D.\n\nTrue. The other half of the issue is that the merge heuristics may have\nimproved between the version of Git used to originally create M and the\nversion of Git used when you are attempting the rebase. The original one\nmay have given a clean but incorrect merge, and your trial merge during a\nrebase may have given a clean and correct merge. The patch D may be the\nright fix-up to apply to M, but it may not be if applied to M'.\n\nIn short, it is not \"quite expensive\", but is fundamentally impossible.\n"},{"id":"188445","messageId":"CABURp0pnXvnT2=fDJXk-yiGctsJBHiNGSCOZiT4Vo74woi0Zxg@mail.gmail.com","threadId":"30117","inReplyTo":"CAH3Anrq_Z0V=DpU1iH-A3F8RFWTG0_C1hEe3iDZYe=AYDTRT3g@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-04-03T22:09:49Z","receivedAt":"2012-04-03T22:09:49Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Apr 3, 2012 at 5:43 PM, Jon Seymour wrote:\n> On Wed, Apr 4, 2012 at 4:55 AM, J Robert Ray wrote:\n>> On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour wrote:\n>>> On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast wrote:\n>>>> Jon Seymour writes:\n> orrectness point of view.\n>>\n>> I thought there would be more concern about the silent data loss.\n>> Instead of throwing away the amended changes I would prefer the rebase\n>> to at least fail, if not have the problem require manual conflict\n>> resolution.\n>>\n>> A warning at the time of the amend could confuse or scare users. But a\n>> mention of this problem in the rebase docs would help.\n>\n> It'd be quite expensive to attempt to detect cases where this might be\n> a problem, but let's articulate, as a thought experiment, what such a\n> solution might look like - I am not suggesting that it is a good idea,\n> but the thought experiment might be illustrative.\n>\n> Suppose you have a merge of a A and B that produces M, which is then\n> amended as M'.\n>\n> During rebase, you redo the merge A and B. If there are no conflicts,\n> then compare M with M' to produce D. You now have enough information\n> to reproduce the amended commit M' during a rebase (merge Ar and,Br\n> then apply D).\n\nHow does M' know it is an amended version of M? When you amended the\ncommit M you threw away this linkage.\n\nIf you created M' as a new commit D instead, then I would agree that\nyou have enough information to do what you seek. In fact, I'm pretty\nsure git does this already.\n\nPhil\n"},{"id":"188469","messageId":"4F7BEA9F.3060805@viscovery.net","threadId":"30117","inReplyTo":"CABURp0pnXvnT2=fDJXk-yiGctsJBHiNGSCOZiT4Vo74woi0Zxg@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-04-04T06:30:55Z","receivedAt":"2012-04-04T06:30:55Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/4/2012 0:09, schrieb Phil Hord:\n> On Tue, Apr 3, 2012 at 5:43 PM, Jon Seymour wrote:\n>> Suppose you have a merge of a A and B that produces M, which is then\n>> amended as M'.\n>>\n>> During rebase, you redo the merge A and B. If there are no conflicts,\n>> then compare M with M' to produce D. You now have enough information\n>> to reproduce the amended commit M' during a rebase (merge Ar and,Br\n>> then apply D).\n> \n> How does M' know it is an amended version of M? When you amended the\n> commit M you threw away this linkage.\n> \n> If you created M' as a new commit D instead, then I would agree that\n> you have enough information to do what you seek. In fact, I'm pretty\n> sure git does this already.\n\nIMO, it is a sub-optimal implementation of rebase -p that it attempts to\nredo the merge. A better strategy is to just replay the changes between\nthe first parent and the merge commit, and then generate a new merge commit:\n\n git diff-tree -p M^ M | git apply --index &&\n git rev-parse M^2 > .git/MERGE_HEAD &&\n git commit -c M\n\nThis would side-step all the issues discussed here, no?\n\n-- Hannes\n"},{"id":"188498","messageId":"7vpqbna0cd.fsf@alter.siamese.dyndns.org","threadId":"30117","inReplyTo":"4F7BEA9F.3060805@viscovery.net","subject":"Re: rebase -p loses amended changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-04T17:11:30Z","receivedAt":"2012-04-04T17:11:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> IMO, it is a sub-optimal implementation of rebase -p that it attempts to\n> redo the merge. A better strategy is to just replay the changes between\n> the first parent and the merge commit, and then generate a new merge commit:\n>\n> git diff-tree -p M^ M | git apply --index &&\n> git rev-parse M^2 > .git/MERGE_HEAD &&\n> git commit -c M\n>\n> This would side-step all the issues discussed here, no?\n\nOr cherry-pick the change made by the merge to its first parent, i.e.\n\n\tgit cherry-pick -m 1 M\n"},{"id":"188526","messageId":"7viphf8cqh.fsf@alter.siamese.dyndns.org","threadId":"30117","inReplyTo":"7vpqbna0cd.fsf@alter.siamese.dyndns.org","subject":"Re: rebase -p loses amended changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-04T20:26:46Z","receivedAt":"2012-04-04T20:26:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Sixt writes:\n>\n>> IMO, it is a sub-optimal implementation of rebase -p that it attempts to\n>> redo the merge. A better strategy is to just replay the changes between\n>> the first parent and the merge commit, and then generate a new merge commit:\n>>\n>> git diff-tree -p M^ M | git apply --index &&\n>> git rev-parse M^2 > .git/MERGE_HEAD &&\n>> git commit -c M\n>>\n>> This would side-step all the issues discussed here, no?\n>\n> Or cherry-pick the change made by the merge to its first parent, i.e.\n>\n> \tgit cherry-pick -m 1 M\n\nErr, that was a confusing unfinished message. I meant the step to replace\nthe part that uses pipe to \"git apply\", more like\n\n git rev-parse M^2 >.git/MERGE_HEAD &&\n\tgit cherry-pick --no-commit -m 1 M &&\n git commit -c M\n\nThe primary difference is that, because \"apply -3\" is not implemented yet,\nthis will help when the base has drifted too much from the corresponding\nblob recorded in M^.\n"},{"id":"188540","messageId":"CAH3AnrrE9Fbs_p_=ETRns4vyz8J879-m+KDF5K4j7vDdTh9bEg@mail.gmail.com","threadId":"30117","inReplyTo":"7viphf8cqh.fsf@alter.siamese.dyndns.org","subject":"Re: rebase -p loses amended changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-04-04T22:55:30Z","receivedAt":"2012-04-04T22:55:30Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 5, 2012 at 6:26 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Johannes Sixt writes:\n>>\n>>> IMO, it is a sub-optimal implementation of rebase -p that it attempts to\n>>> redo the merge. A better strategy is to just replay the changes between\n>>> the first parent and the merge commit, and then generate a new merge commit:\n>>>\n>>>    git diff-tree -p M^ M | git apply --index &&\n>>>    git rev-parse M^2 > .git/MERGE_HEAD &&\n>>>    git commit -c M\n>>>\n>>> This would side-step all the issues discussed here, no?\n>>\n>> Or cherry-pick the change made by the merge to its first parent, i.e.\n>>\n>>       git cherry-pick -m 1 M\n>\n> Err, that was a confusing unfinished message.  I meant the step to replace\n> the part that uses pipe to \"git apply\", more like\n>\n>        git rev-parse M^2 >.git/MERGE_HEAD &&\n>        git cherry-pick --no-commit -m 1 M &&\n>        git commit -c M\n>\n> The primary difference is that, because \"apply -3\" is not implemented yet,\n> this will help when the base has drifted too much from the corresponding\n> blob recorded in M^.\n>\n\nAh, not so impossible after all :-).\n\nYeah, I know, you were talking specifically about the approach\nsuggested in my thought experiment.\n\nIt does seem like such an approach would yield an outcome much closer\nto J Robert Ray's expectation.\n\nGood suggestion, Hannes! Are there any flaws, I wonder?\n\njon.\n"},{"id":"188541","messageId":"7vlimb6r37.fsf@alter.siamese.dyndns.org","threadId":"30117","inReplyTo":"CAH3AnrrE9Fbs_p_=ETRns4vyz8J879-m+KDF5K4j7vDdTh9bEg@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-04T22:59:40Z","receivedAt":"2012-04-04T22:59:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> Are there any flaws, I wonder?\n\nIt all depends on how close the base is to M^1. The difference might make\nit unnecessary (or even more necessary) to do any evil merge.\n"},{"id":"188542","messageId":"CAH3AnrphGmrZSxALP3j3ADt6Cg4Tr2O83mcDBU2LfUdpdtUCUw@mail.gmail.com","threadId":"30117","inReplyTo":"7vlimb6r37.fsf@alter.siamese.dyndns.org","subject":"Re: rebase -p loses amended changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-04-04T23:05:16Z","receivedAt":"2012-04-04T23:05:16Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 5, 2012 at 8:59 AM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>> Are there any flaws, I wonder?\n>\n> It all depends on how close the base is to M^1.  The difference might make\n> it unnecessary (or even more necessary) to do any evil merge.\n\nTrue. I guess it is still true there are no perfect solutions in this\narea. This does seem like a step in a better direction, though.\n\njon.\n"},{"id":"188543","messageId":"7vhawz6q3v.fsf@alter.siamese.dyndns.org","threadId":"30117","inReplyTo":"CAH3AnrphGmrZSxALP3j3ADt6Cg4Tr2O83mcDBU2LfUdpdtUCUw@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-04T23:20:52Z","receivedAt":"2012-04-04T23:20:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> On Thu, Apr 5, 2012 at 8:59 AM, Junio C Hamano wrote:\n>> Jon Seymour writes:\n>>\n>>> Are there any flaws, I wonder?\n>>\n>> It all depends on how close the base is to M^1. ...\n>\n> True. I guess it is still true there are no perfect solutions in this\n> area. This does seem like a step in a better direction, though.\n\nThe nice thing about Hannes's \"replay the change between M^1 and M\" is\nthat it sidesteps the fundamentally impossible part of your original idea,\nwhich is to mechanically sift the \"evil\" part out of \"pure merge\" part\nout. Instead, it replays the change as a single ball of wax.\n\nThat difference between these two approaches may make the replaying of M\neasier or harder, depending on how M^1 and your new base relate to each\nother, so it is hard to say if it is really a step in a better direction.\nPerhaps M is a merge made to the maint branch, and you may be replaying it\non top of a newer codebase based on the master track. M^1 may lack many\nchanges the new base has, so replaying M by applying the patch between M^1\nand M may give you a lot of conflict that you should not have to resolve\nif you simply merged M^2 to the new base. And the worst part of this\nconflict resolution is that you cannot easily tell what the right solution\nshould be unless you look at M, M^1 and M^2---that forces you to sift the\n\"evil\" part out of \"pure merge\" part in the original merge. The good news\nis that this is *not* mechanical, as you have your own intelligence to\nhelp that process ;-)\n"},{"id":"188570","messageId":"CAOeW2eHHW6de1qcnajV7DLzWyiSJyh+ZpMbhQU-1WKnRuSeNhg@mail.gmail.com","threadId":"30117","inReplyTo":"4F7BEA9F.3060805@viscovery.net","subject":"Re: rebase -p loses amended changes","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2012-04-05T16:16:54Z","receivedAt":"2012-04-05T16:16:54Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Tue, Apr 3, 2012 at 11:30 PM, Johannes Sixt wrote:\n> IMO, it is a sub-optimal implementation of rebase -p that it attempts to\n> redo the merge. A better strategy is to just replay the changes between\n> the first parent and the merge commit, and then generate a new merge commit:\n>\n>   git diff-tree -p M^ M | git apply --index &&\n>   git rev-parse M^2 > .git/MERGE_HEAD &&\n>   git commit -c M\n>\n> This would side-step all the issues discussed here, no?\n\nMaybe. How would it handle the following, though?\n\nWith this history\n\n .-e-.\n / \\\n .-c---d---f\n /\na---b---g\n\n, \"git rebase -p --onto g b f\" produces\n\n\n .-e'.\n / \\\na---b---g---c'--d'--f'\n\nIf the merge was interactive (or was made interactive due to merge\nconflicts), e'-c' (the diff between c' and e') might be very different\nfrom e-c. Creating f' by replaying f-d on top of d' would lose any\nchanges done in e'-c' as compared to e-c, no?\n\nSorry I this has already been said or if I'm missing the point; I have\nnot been following the conversion completely.\n\nMartin\n"},{"id":"188569","messageId":"CAH3AnrrYVNDN4cY7EmFsFyjC50wifuoPj1jSLPTxsSUy5+4aiQ@mail.gmail.com","threadId":"30117","inReplyTo":"CAOeW2eHHW6de1qcnajV7DLzWyiSJyh+ZpMbhQU-1WKnRuSeNhg@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-04-05T16:33:52Z","receivedAt":"2012-04-05T16:33:52Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":">\n> With this history\n>\n>          .-e-.\n>         /     \\\n>      .-c---d---f\n>     /\n> a---b---g\n>\n> , \"git rebase -p --onto g b f\" produces\n>\n>\n>              .-e'.\n>             /     \\\n> a---b---g---c'--d'--f'\n>\n\nPerhaps there is a a formatting issue here, but wouldn't the resulting\nhistory be, instead:\n\n               . -e'.\n             /     \\\n a---b---g---c'--d'--f'\n\nI don't really understand why e' - c' would be different to e-c?\n\njon.\n"},{"id":"188571","messageId":"CAOeW2eHJYiHswmzJeMnce5cpcA7zFi7kiH9CsZdNcHB7G+CtUA@mail.gmail.com","threadId":"30117","inReplyTo":"CAH3AnrrYVNDN4cY7EmFsFyjC50wifuoPj1jSLPTxsSUy5+4aiQ@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2012-04-05T16:43:34Z","receivedAt":"2012-04-05T16:43:34Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, Apr 5, 2012 at 9:33 AM, Jon Seymour wrote:\n>>\n>> With this history\n>>\n>>          .-e-.\n>>         /     \\\n>>      .-c---d---f\n>>     /\n>> a---b---g\n>>\n>> , \"git rebase -p --onto g b f\" produces\n>>\n>>\n>>              .-e'.\n>>             /     \\\n>> a---b---g---c'--d'--f'\n>>\n>\n> Perhaps there is a a formatting issue here, but wouldn't the resulting\n> history be, instead:\n>\n>                  . -e'.\n>                 /     \\\n>  a---b---g---c'--d'--f'\n\nThat's how it looked before I pasted it into gmail. Sorry about that\nand thanks for clarifying.\n\n> I don't really understand why e' - c' would be different to e-c?\n\nNot \"would\", but \"could\", if you're using -i as well and choose the\n\"edit\" action for commit e (or if merge conflict makes it halt while\ncreating e').\n"},{"id":"188853","messageId":"4F83DDCE.1040000@viscovery.net","threadId":"30117","inReplyTo":"CAOeW2eHHW6de1qcnajV7DLzWyiSJyh+ZpMbhQU-1WKnRuSeNhg@mail.gmail.com","subject":"Re: rebase -p loses amended changes","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-04-10T07:14:22Z","receivedAt":"2012-04-10T07:14:22Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/5/2012 18:16, schrieb Martin von Zweigbergk:\n> On Tue, Apr 3, 2012 at 11:30 PM, Johannes Sixt wrote:\n>> IMO, it is a sub-optimal implementation of rebase -p that it attempts to\n>> redo the merge. A better strategy is to just replay the changes between\n>> the first parent and the merge commit, and then generate a new merge commit:\n>>\n>> git diff-tree -p M^ M | git apply --index &&\n>> git rev-parse M^2 > .git/MERGE_HEAD &&\n>> git commit -c M\n>>\n>> This would side-step all the issues discussed here, no?\n> \n> Maybe. How would it handle the following, though?\n> \n> With this history\n> \n> .-e-.\n> / \\\n> .-c---d---f\n> /\n> a---b---g\n> \n> , \"git rebase -p --onto g b f\" produces\n> \n> \n> .-e'.\n> / \\\n> a---b---g---c'--d'--f'\n> \n> If the merge was interactive (or was made interactive due to merge\n> conflicts), e'-c' (the diff between c' and e') might be very different\n> from e-c. Creating f' by replaying f-d on top of d' would lose any\n> changes done in e'-c' as compared to e-c, no?\n\nIf I understand correctly, rebase -p is not intended to move branchy\nhistory to a new fork point (that would be the task of the still\nhypothetical generic sequencer). Its purpose is only to keep the merges of\nother \"unrelated\" topics, e.g.:\n\n...--o--o <- bugfix topic (needed by my-topic)\n \\\n x--y--M--z <- my-topic\n /\n--A--o--o--B <- master\n\nto be turned into\n\n...--o--o--------. <- bugfix topic (needed by my-topic)\n \\\n x'-y'-M'-z' <- my-topic\n /\n--A--o--o--B <- master\n\n-- Hannes\n"}]}