{"thread":{"id":"42299","subject":"bug report","startedAt":"2016-05-13T05:04:24Z","lastAt":"2016-05-13T12:05:16Z","messageCount":9,"participants":["李本超","Pranit Bauva","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"286422","messageId":"CABKuJ_SN+Ynsi9-48-iKgC1n9ARZe3ZjQR9Y2q3=tYC=QGgfZQ@mail.gmail.com","threadId":"42299","inReplyTo":null,"subject":"bug report","fromName":"李本超","fromEmail":"libenchao@gmail.com","sentAt":"2016-05-13T05:04:24Z","receivedAt":"2016-05-13T05:04:24Z","isPatch":false,"sender":{"key":"libenchao@gmail.com","avatar":null},"body":"Hi all,\n\n      Yestoday when I worked using Git, I found a bug. It's about\nrebase. Or I don't know if it is a bug, maybe that is Git. Below is my\nproblem:\n\n      There is a master branch, and we develop in our own branch.\nLet's simplify this: there are two branches created at the same commit\npoint at master. Then branch A add a function X. Branch B add funciton\nX too (yes, they are very same). Then branch B modify function X to\nfunction Y.\n      Branch A finishes it's job first and merged to master\nsuccessfully and happily without any conflicts. When branch B wants to\nmerge to master, he finds that master has updated. So branch B must\nrebase to the current master. Then problem happends: git rebase\nsuccessfully without any conflicts. But branch B cannot see function X\nfrom master (or branch A), only its own function Y.\n      I think that's because Git is based on file instead of patch.\nBut I think Git can report it in this situation.\n      How do you think ? Thank you anyway for maintaining this amazing software.\n\n-- \n\nBenchao Li\nSchool of Electronics Engineering and Computer Science, Peking University\nTel:+86-15650713730\nEmail: libenchao@gmail.com; libenchao@pku.edu.cn\n"},{"id":"286423","messageId":"CAFZEwPNCEAU-sexn-dFr8dDg=_w02hLOhfQhKu_yRYtY3LeJHw@mail.gmail.com","threadId":"42299","inReplyTo":"CABKuJ_SN+Ynsi9-48-iKgC1n9ARZe3ZjQR9Y2q3=tYC=QGgfZQ@mail.gmail.com","subject":"Re: bug report","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-05-13T05:23:52Z","receivedAt":"2016-05-13T05:23:52Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"Please mention the version no of git you are using and your system.\nI am answering according to git 2.8.1 Lubuntu 15.04\n\nOn Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:\n> Hi all,\n>\n>       Yestoday when I worked using Git, I found a bug. It's about\n> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my\n> problem:\n>\n>       There is a master branch, and we develop in our own branch.\n> Let's simplify this: there are two branches created at the same commit\n> point at master. Then branch A add a function X. Branch B add funciton\n> X too (yes, they are very same). Then branch B modify function X to\n> function Y.\n\nWhat do you mean by this? Did you amend the previous commit, or\nintroduced another separate commit ?\n\n>       Branch A finishes it's job first and merged to master\n> successfully and happily without any conflicts. When branch B wants to\n> merge to master, he finds that master has updated. So branch B must\n> rebase to the current master. Then problem happends: git rebase\n> successfully without any conflicts. But branch B cannot see function X\n> from master (or branch A), only its own function Y.\n>       I think that's because Git is based on file instead of patch.\n> But I think Git can report it in this situation.\n>       How do you think ? Thank you anyway for maintaining this amazing software.\n\nWell I tried to reproduce the problem. I did the following steps:\n$ mdkir test_repo\n$ cd test_repo\n$ git init\n$ echo Hello >hi\n$ git commit -a -m \"C1\"\n$ git checkout -b A\n$ echo Bye >hi\n$ git commit -a -m \"C2 - A\"\n$ git checkout -\n$ git checkout -b B\n$ echo \"Bye.\" >hi\n$ git commit -a -m \"C3 - B\"\n$ git checkout -\n$ git merge A\n$ git checkout B\n$ git rebase master\n\nThis shows that some merge conflicts needs resolving. Did I follow\nyour steps or I missed something? It would be better if you could\nreproduce your steps like I did so as to make things more clear to us.\n\nRegards,\nPranit Bauva\n"},{"id":"286427","messageId":"CABKuJ_QZHTRcPWbwv1FSXEijxOpXameo-JJuZREGyA5daLbKLQ@mail.gmail.com","threadId":"42299","inReplyTo":"CAFZEwPNCEAU-sexn-dFr8dDg=_w02hLOhfQhKu_yRYtY3LeJHw@mail.gmail.com","subject":"Re: bug report","fromName":"李本超","fromEmail":"libenchao@gmail.com","sentAt":"2016-05-13T05:58:43Z","receivedAt":"2016-05-13T05:58:43Z","isPatch":false,"sender":{"key":"libenchao@gmail.com","avatar":null},"body":"git version 2.6.4 (Apple Git-63)\nsystem version: OS X EI Capitan 10.11.4\n\nbelow is the steps:\n$ mkdir test_repo\n$ cd test_repo\n$ git init\n$ echo \"hello\" > README.md\n$ git commit -a -m 'Add README.md'\n\n$ git checkout -b A\n$ echo \"world\" > README.md\n$ git commit -a -m 'Add one line'\n\n$ git checkout master\n$ git checkout -b B\n$ echo \"world\" > README.md\n$ git commit -a -m 'Add one line too'\n$ [midify 'world' line to other things like 'git' using vi]\n$ git commit -a -m 'Modify one line'\n\n$ git checkout master\n$ git merge A\n\n$ git checkout B\n$ git rebase master [problem is here, cat README.rd we will get :\nhello and git instead of hello world git]\n\n2016-05-13 13:23 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:\n> Please mention the version no of git you are using and your system.\n> I am answering according to git 2.8.1 Lubuntu 15.04\n>\n> On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:\n>> Hi all,\n>>\n>>       Yestoday when I worked using Git, I found a bug. It's about\n>> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my\n>> problem:\n>>\n>>       There is a master branch, and we develop in our own branch.\n>> Let's simplify this: there are two branches created at the same commit\n>> point at master. Then branch A add a function X. Branch B add funciton\n>> X too (yes, they are very same). Then branch B modify function X to\n>> function Y.\n>\n> What do you mean by this? Did you amend the previous commit, or\n> introduced another separate commit ?\n>\n>>       Branch A finishes it's job first and merged to master\n>> successfully and happily without any conflicts. When branch B wants to\n>> merge to master, he finds that master has updated. So branch B must\n>> rebase to the current master. Then problem happends: git rebase\n>> successfully without any conflicts. But branch B cannot see function X\n>> from master (or branch A), only its own function Y.\n>>       I think that's because Git is based on file instead of patch.\n>> But I think Git can report it in this situation.\n>>       How do you think ? Thank you anyway for maintaining this amazing software.\n>\n> Well I tried to reproduce the problem. I did the following steps:\n> $ mdkir test_repo\n> $ cd test_repo\n> $ git init\n> $ echo Hello >hi\n> $ git commit -a -m \"C1\"\n> $ git checkout -b A\n> $ echo Bye >hi\n> $ git commit -a -m \"C2 - A\"\n> $ git checkout -\n> $ git checkout -b B\n> $ echo \"Bye.\" >hi\n> $ git commit -a -m \"C3 - B\"\n> $ git checkout -\n> $ git merge A\n> $ git checkout B\n> $ git rebase master\n>\n> This shows that some merge conflicts needs resolving. Did I follow\n> your steps or I missed something? It would be better if you could\n> reproduce your steps like I did so as to make things more clear to us.\n>\n> Regards,\n> Pranit Bauva\n\n\n\n-- \nBenchao Li\nSchool of Electronics Engineering and Computer Science, Peking University\nTel:+86-15650713730\nEmail: libenchao@gmail.com; libenchao@pku.edu.cn\n"},{"id":"286431","messageId":"CAFZEwPP32vWrCA9H+JbFineodDtGx2_bTjGy-nZ9KW2v8bP5vQ@mail.gmail.com","threadId":"42299","inReplyTo":"CABKuJ_QZHTRcPWbwv1FSXEijxOpXameo-JJuZREGyA5daLbKLQ@mail.gmail.com","subject":"Re: bug report","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-05-13T06:37:57Z","receivedAt":"2016-05-13T06:37:57Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:\n> git version 2.6.4 (Apple Git-63)\n> system version: OS X EI Capitan 10.11.4\n>\n> below is the steps:\n> $ mkdir test_repo\n> $ cd test_repo\n> $ git init\n> $ echo \"hello\" > README.md\n> $ git commit -a -m 'Add README.md'\n\nIt was my mistake. git-commit -a adds files which are tracked.\nCurrently README.md is not tracked. So you will have to first use\ngit-add to add them for tracking. Though while trying out your steps I\nused git-add. For further commits one can use -a with git-commit.\n\n> $ git checkout -b A\n> $ echo \"world\" > README.md\n> $ git commit -a -m 'Add one line'\n\nYou are technically not adding a line. You are modifying the previous\nline to the updated line. So the contents of the file will be:\n\"world\"\nIt seems from the further part that you actually wanted to add the\nline rather than modifying it. Better to use \">>\" instead of \">\". \">>\"\nis used for appending.\n\n> $ git checkout master\n> $ git checkout -b B\n> $ echo \"world\" > README.md\n> $ git commit -a -m 'Add one line too'\n> $ [midify 'world' line to other things like 'git' using vi]\n\nI think you mean modify.\n\n> $ git commit -a -m 'Modify one line'\n>\n> $ git checkout master\n> $ git merge A\n>\n> $ git checkout B\n> $ git rebase master [problem is here, cat README.rd we will get :\n> hello and git instead of hello world git]\n\nThe git behavior is quite correct.\nWhen you are on the B branch and you choose to rebase it on the\nmaster, it will apply commits as patches. So it first sees that the\ncommit on the A branch which is now merged with master ie. \"Add one\nline\" and the commit on the B branch \"Add one line too\" are doing the\nsame thing which is removing the line \"hello\" and adding the line\n\"world\". Then it applies the commit \"modify one line\" on top of this\nwhich removes the line \"world\" and adds the line \"git\". So finally,\nREADME.md will contain only \"git\".\n\nRegards,\nPranit Bauva\n"},{"id":"286433","messageId":"CABKuJ_SEK-t93sCmj6aFSAbk8muX_ocQx6ZQZV3ZrNmvVmvDQA@mail.gmail.com","threadId":"42299","inReplyTo":"CAFZEwPP32vWrCA9H+JbFineodDtGx2_bTjGy-nZ9KW2v8bP5vQ@mail.gmail.com","subject":"Re: bug report","fromName":"李本超","fromEmail":"libenchao@gmail.com","sentAt":"2016-05-13T06:57:25Z","receivedAt":"2016-05-13T06:57:25Z","isPatch":false,"sender":{"key":"libenchao@gmail.com","avatar":null},"body":"Yes, you got the right understanding of my problem.\n\nYou are right, the git behavior is quite correct. But I met this\nproblem in my practical work:\n\nMy colleague added a method but I didn't know. I also added the same method.\nThen I found that I didn't need the method actually, so I deleted it.\nMy colleague merged to the master before me. When I wanted to merge, I found\nconflicts with master. And I rebased to current master. And That method was\ndeleted finally without any warning or information.\n\nDo you think Git should output something to warn the user or I just\nuse Git in a wrong way ?\n\nThanks.\n\n2016-05-13 14:37 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:\n> On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:\n>> git version 2.6.4 (Apple Git-63)\n>> system version: OS X EI Capitan 10.11.4\n>>\n>> below is the steps:\n>> $ mkdir test_repo\n>> $ cd test_repo\n>> $ git init\n>> $ echo \"hello\" > README.md\n>> $ git commit -a -m 'Add README.md'\n>\n> It was my mistake. git-commit -a adds files which are tracked.\n> Currently README.md is not tracked. So you will have to first use\n> git-add to add them for tracking. Though while trying out your steps I\n> used git-add. For further commits one can use -a with git-commit.\n>\n>> $ git checkout -b A\n>> $ echo \"world\" > README.md\n>> $ git commit -a -m 'Add one line'\n>\n> You are technically not adding a line. You are modifying the previous\n> line to the updated line. So the contents of the file will be:\n> \"world\"\n> It seems from the further part that you actually wanted to add the\n> line rather than modifying it. Better to use \">>\" instead of \">\". \">>\"\n> is used for appending.\n>\n>> $ git checkout master\n>> $ git checkout -b B\n>> $ echo \"world\" > README.md\n>> $ git commit -a -m 'Add one line too'\n>> $ [midify 'world' line to other things like 'git' using vi]\n>\n> I think you mean modify.\n>\n>> $ git commit -a -m 'Modify one line'\n>>\n>> $ git checkout master\n>> $ git merge A\n>>\n>> $ git checkout B\n>> $ git rebase master [problem is here, cat README.rd we will get :\n>> hello and git instead of hello world git]\n>\n> The git behavior is quite correct.\n> When you are on the B branch and you choose to rebase it on the\n> master, it will apply commits as patches. So it first sees that the\n> commit on the A branch which is now merged with master ie. \"Add one\n> line\" and the commit on the B branch \"Add one line too\" are doing the\n> same thing which is removing the line \"hello\" and adding the line\n> \"world\". Then it applies the commit \"modify one line\" on top of this\n> which removes the line \"world\" and adds the line \"git\". So finally,\n> README.md will contain only \"git\".\n>\n> Regards,\n> Pranit Bauva\n\n\n\n-- \nBenchao Li\nSchool of Electronics Engineering and Computer Science, Peking University\nTel:+86-15650713730\nEmail: libenchao@gmail.com; libenchao@pku.edu.cn\n"},{"id":"286435","messageId":"CAFZEwPMe2W2R2GghMnyQ4BLyvm00oHEweNSZYrqn+=9BhSazvw@mail.gmail.com","threadId":"42299","inReplyTo":"CABKuJ_SEK-t93sCmj6aFSAbk8muX_ocQx6ZQZV3ZrNmvVmvDQA@mail.gmail.com","subject":"Re: bug report","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-05-13T07:10:39Z","receivedAt":"2016-05-13T07:10:39Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:\n> Yes, you got the right understanding of my problem.\n>\n> You are right, the git behavior is quite correct. But I met this\n> problem in my practical work:\n>\n> My colleague added a method but I didn't know. I also added the same method.\n> Then I found that I didn't need the method actually, so I deleted it.\n> My colleague merged to the master before me. When I wanted to merge, I found\n> conflicts with master. And I rebased to current master. And That method was\n> deleted finally without any warning or information.\n\nI am quite sure that there would be an output to show that there are\nconflicts and it would be suggesting you to first resolve the\nconflicts and there would also be markers in the file like \">>>>>\" and\n\"======\" and the file would be marked with \"both modified\". After you\nresolve the conflicts, you can add the file by using git-add and then\n\"git rebase --continue\" to proceed. If you find out that there is some\nproblem, then you can always use \"git rebase --abort\" to abort the\nrebase process and get to the initial state *perfectly* without any\nglitches.\n\n> Do you think Git should output something to warn the user or I just\n> use Git in a wrong way ?\n\nIt does warn. I don't know how it got missed in your case. This is\nquite a common problem and even I have faced this quite for quite a\nlot of times now and it always did warn me.\n\n> Thanks.\n\nI will recommend you reading this article[1]. I know its a bit of a\nlong read but it will help a lot.\n\n[1]: http://tedfelix.com/software/git-conflict-resolution.html\n\nRegards,\nPranit Bauva\n"},{"id":"286437","messageId":"CABKuJ_RrOhT+FVb9PNKhBs1ATJmLWhD757oyx+AvrCGNvT1nFw@mail.gmail.com","threadId":"42299","inReplyTo":"CAFZEwPMe2W2R2GghMnyQ4BLyvm00oHEweNSZYrqn+=9BhSazvw@mail.gmail.com","subject":"Re: bug report","fromName":"李本超","fromEmail":"libenchao@gmail.com","sentAt":"2016-05-13T07:41:13Z","receivedAt":"2016-05-13T07:41:13Z","isPatch":false,"sender":{"key":"libenchao@gmail.com","avatar":null},"body":"It does not warn me in this case. I replayed it again, below is my process:\n\n$ mkdir bug_test\n$ cd bug_test/\n$ git init\nInitialized empty Git repository in /home/libenchao/tmp/bug_test/.git/\n$ echo 'hello' > README.md\n$ git add README.md\n$ git commit -m 'Add README.md'\n[master (root-commit) 9cdb3a8] Add README.md\n 1 file changed, 1 insertion(+)\n create mode 100644 README.md\n$ git checkout -b A\nSwitched to a new branch 'A'\n$ echo 'world' >> README.md\n$ git commit -a -m 'Add one line'\n[A 6f0b0a3] Add one line\n 1 file changed, 1 insertion(+)\n$ git checkout master\nSwitched to branch 'master'\n$ git checkout -b B\nSwitched to a new branch 'B'\n$ echo 'world' >> README.md\n$ git commit -a -m 'Add one line too'\n[B d89cf11] Add one line too\n 1 file changed, 1 insertion(+)\n$ vim README.md                        # in this line, I modify line 2\n'world' to 'git'\n$ cat README.md\nhello\ngit\n$ git commit -a -m 'Modify one line'\n[B a674427] Modify one line\n 1 file changed, 1 insertion(+), 1 deletion(-)\n$ git checkout master\nSwitched to branch 'master'\n$ git merge A\nUpdating 9cdb3a8..6f0b0a3\nFast-forward\n README.md | 1 +\n 1 file changed, 1 insertion(+)\n$ git checkout B\nSwitched to branch 'B'\n$ git rebase master\nFirst, rewinding head to replay your work on top of it...\nApplying: Modify one line\n$ cat README.md\nhello\ngit\n$\n\n2016-05-13 15:10 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:\n> On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:\n>> Yes, you got the right understanding of my problem.\n>>\n>> You are right, the git behavior is quite correct. But I met this\n>> problem in my practical work:\n>>\n>> My colleague added a method but I didn't know. I also added the same method.\n>> Then I found that I didn't need the method actually, so I deleted it.\n>> My colleague merged to the master before me. When I wanted to merge, I found\n>> conflicts with master. And I rebased to current master. And That method was\n>> deleted finally without any warning or information.\n>\n> I am quite sure that there would be an output to show that there are\n> conflicts and it would be suggesting you to first resolve the\n> conflicts and there would also be markers in the file like \">>>>>\" and\n> \"======\" and the file would be marked with \"both modified\". After you\n> resolve the conflicts, you can add the file by using git-add and then\n> \"git rebase --continue\" to proceed. If you find out that there is some\n> problem, then you can always use \"git rebase --abort\" to abort the\n> rebase process and get to the initial state *perfectly* without any\n> glitches.\n>\n>> Do you think Git should output something to warn the user or I just\n>> use Git in a wrong way ?\n>\n> It does warn. I don't know how it got missed in your case. This is\n> quite a common problem and even I have faced this quite for quite a\n> lot of times now and it always did warn me.\n>\n>> Thanks.\n>\n> I will recommend you reading this article[1]. I know its a bit of a\n> long read but it will help a lot.\n>\n> [1]: http://tedfelix.com/software/git-conflict-resolution.html\n>\n> Regards,\n> Pranit Bauva\n\n\n\n-- \nBenchao Li\nSchool of Electronics Engineering and Computer Science, Peking University\nTel:+86-15650713730\nEmail: libenchao@gmail.com; libenchao@pku.edu.cn\n"},{"id":"286438","messageId":"20160513081014.GA18307@sigill.intra.peff.net","threadId":"42299","inReplyTo":"CABKuJ_RrOhT+FVb9PNKhBs1ATJmLWhD757oyx+AvrCGNvT1nFw@mail.gmail.com","subject":"Re: bug report","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-13T08:10:15Z","receivedAt":"2016-05-13T08:10:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:\n\n> It does not warn me in this case. I replayed it again, below is my process:\n> \n> [...setup...]\n\nSo after you setup steps you have:\n\n  $ git log --decorate --oneline --raw\n\n  * a3ce3bc (HEAD -> B) modify\n  | :100644 100644 94954ab... 23509e0... M        README.md\n  * ef702eb add one line too\n  | :100644 100644 ce01362... 94954ab... M        README.md\n  | * fa8b99e (master, A) add one line\n  |/  \n  |   :100644 100644 ce01362... 94954ab... M      README.md\n  * cf2103b add readme\n    :000000 100644 0000000... ce01362... A        README.md\n\nNote that B^ (ef702eb) and A (fa8b99e) introduce the exact same change\n(moving README.md from ce01362 to 94954ab). And master is at the same\ncommit as A (due to your fast-forward merge earlier).\n\nSo now when you run:\n\n> $ git rebase master\n\nGit will try to replay the commits on master..B on top of master, in\norder.  Those commits are ef702eb and a3ce3bc (your commit names will\ndiffer, because your name and timestamps will differ).\n\nSo it replays the first one, and sees that it the patch is a noop[1];\nthe tree in master already has the same end state. So we skip the patch.\nAnd then we replay the second one, which applies cleanly.\n\nThe moment where I think you'd like to be notified is when we skipped\ndoing anything with patch 1. You'd prefer it to say \"woah, the other\nside of the rebase did the same thing as us\".\n\nBut rebase does not do that by default, because the intent of rebase is\nthat you are rebasing your work on an upstream which might be accepting\npart of your work as patches. So it is a feature that rebase says\n\"already applied upstream -- let's ignore this one\".\n\nI don't think there is a way to ask rebase not to ignore such\nalready-applied patches. But I'm not sure if there should be, for two\nreasons:\n\n  1. You should consider just using \"git merge\" to merge the two\n     branches. That preserves more information about what actually\n     happened, and would find a conflict in a case like this.\n\n  2. Even with merging, you cannot assume that the end result is sane.\n     In your example, there is a textual conflict. But you can easily\n     come up with other examples where a merge is textually sound, but\n     has some semantic conflict (e.g., you update the signature of a\n     function but a colleague adds another call to it using the old\n     signature).\n\n     You have to examine and test the results of merges for sanity. And\n     likewise with rebases.\n\n-Peff\n\n[1] Actually, rebase does not even try to replay the first patch. When\n    it generates the list of commits, it ignores any whose \"patch-id\" is\n    the same as a commit on the other side. But the end effect is the\n    same.\n"},{"id":"286448","messageId":"CABKuJ_SwJhjZCgL3KkHA7p2QfStW-g5oEi8qhNGXoNb721Ynhg@mail.gmail.com","threadId":"42299","inReplyTo":"20160513081014.GA18307@sigill.intra.peff.net","subject":"Re: bug report","fromName":"李本超","fromEmail":"libenchao@gmail.com","sentAt":"2016-05-13T12:05:16Z","receivedAt":"2016-05-13T12:05:16Z","isPatch":false,"sender":{"key":"libenchao@gmail.com","avatar":null},"body":"Thanks for your explanation\n\n>\n> The moment where I think you'd like to be notified is when we skipped\n> doing anything with patch 1. You'd prefer it to say \"woah, the other\n> side of the rebase did the same thing as us\".\nActually this is the problem where I want to be notified.\n\n> But rebase does not do that by default, because the intent of rebase is\n> that you are rebasing your work on an upstream which might be accepting\n> part of your work as patches. So it is a feature that rebase says\n> \"already applied upstream -- let's ignore this one\".\n>\n> I don't think there is a way to ask rebase not to ignore such\n> already-applied patches. But I'm not sure if there should be, for two\n> reasons:\n>\n>   1. You should consider just using \"git merge\" to merge the two\n>      branches. That preserves more information about what actually\n>      happened, and would find a conflict in a case like this.\n>\n>   2. Even with merging, you cannot assume that the end result is sane.\n>      In your example, there is a textual conflict. But you can easily\n>      come up with other examples where a merge is textually sound, but\n>      has some semantic conflict (e.g., you update the signature of a\n>      function but a colleague adds another call to it using the old\n>      signature).\n>\n>      You have to examine and test the results of merges for sanity. And\n>      likewise with rebases.\n>\n> -Peff\n>\n> [1] Actually, rebase does not even try to replay the first patch. When\n>     it generates the list of commits, it ignores any whose \"patch-id\" is\n>     the same as a commit on the other side. But the end effect is the\n>     same.\nYour explanation looks reasonable to me.\n\nThanks a lot for your time and patience. And @Pranit Bauva too.\n\nBy the way, many thanks for maintaining this outstanding software Git.\n\n\n-- \nBenchao Li\nSchool of Electronics Engineering and Computer Science, Peking University\nTel:+86-15650713730\nEmail: libenchao@gmail.com; libenchao@pku.edu.cn\n"}]}