bug report
Hi all, Yestoday when I worked using Git, I found a bug. It's about rebase. Or I don't know if it is a bug, maybe that is Git. Below is my problem: There is a master branch, and we develop in our own branch. Let's simplify this: there are two branches created at the same commit point at master. Then branch A add a function X. Branch B add funciton X too (yes, they are very same). Then branch B modify function X to function Y. Branch A finishes it's job first and merged to master successfully and happily without any conflicts. When branch B wants to merge to master, he finds that master has updated. So branch B must rebase to the current master. Then problem happends: git rebase successfully without any conflicts. But branch B cannot see function X from master (or branch A), only its own function Y. I think that's because Git is based on file instead of patch. But I think Git can report it in this situation. How do you think ? Thank you anyway for maintaining this amazing software. -- Benchao Li School of Electronics Engineering and Computer Science, Peking University Tel:+86-15650713730 Email: libenc...@gmail.com; libenc...@pku.edu.cn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report
git version 2.6.4 (Apple Git-63) system version: OS X EI Capitan 10.11.4 below is the steps: $ mkdir test_repo $ cd test_repo $ git init $ echo "hello" > README.md $ git commit -a -m 'Add README.md' $ git checkout -b A $ echo "world" > README.md $ git commit -a -m 'Add one line' $ git checkout master $ git checkout -b B $ echo "world" > README.md $ git commit -a -m 'Add one line too' $ [midify 'world' line to other things like 'git' using vi] $ git commit -a -m 'Modify one line' $ git checkout master $ git merge A $ git checkout B $ git rebase master [problem is here, cat README.rd we will get : hello and git instead of hello world git] 2016-05-13 13:23 GMT+08:00 Pranit Bauva : > Please mention the version no of git you are using and your system. > I am answering according to git 2.8.1 Lubuntu 15.04 > > On Fri, May 13, 2016 at 10:34 AM, 李本超 wrote: >> Hi all, >> >> Yestoday when I worked using Git, I found a bug. It's about >> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my >> problem: >> >> There is a master branch, and we develop in our own branch. >> Let's simplify this: there are two branches created at the same commit >> point at master. Then branch A add a function X. Branch B add funciton >> X too (yes, they are very same). Then branch B modify function X to >> function Y. > > What do you mean by this? Did you amend the previous commit, or > introduced another separate commit ? > >> Branch A finishes it's job first and merged to master >> successfully and happily without any conflicts. When branch B wants to >> merge to master, he finds that master has updated. So branch B must >> rebase to the current master. Then problem happends: git rebase >> successfully without any conflicts. But branch B cannot see function X >> from master (or branch A), only its own function Y. >> I think that's because Git is based on file instead of patch. >> But I think Git can report it in this situation. >> How do you think ? Thank you anyway for maintaining this amazing >> software. > > Well I tried to reproduce the problem. I did the following steps: > $ mdkir test_repo > $ cd test_repo > $ git init > $ echo Hello >hi > $ git commit -a -m "C1" > $ git checkout -b A > $ echo Bye >hi > $ git commit -a -m "C2 - A" > $ git checkout - > $ git checkout -b B > $ echo "Bye." >hi > $ git commit -a -m "C3 - B" > $ git checkout - > $ git merge A > $ git checkout B > $ git rebase master > > This shows that some merge conflicts needs resolving. Did I follow > your steps or I missed something? It would be better if you could > reproduce your steps like I did so as to make things more clear to us. > > Regards, > Pranit Bauva -- Benchao Li School of Electronics Engineering and Computer Science, Peking University Tel:+86-15650713730 Email: libenc...@gmail.com; libenc...@pku.edu.cn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report
Yes, you got the right understanding of my problem. You are right, the git behavior is quite correct. But I met this problem in my practical work: My colleague added a method but I didn't know. I also added the same method. Then I found that I didn't need the method actually, so I deleted it. My colleague merged to the master before me. When I wanted to merge, I found conflicts with master. And I rebased to current master. And That method was deleted finally without any warning or information. Do you think Git should output something to warn the user or I just use Git in a wrong way ? Thanks. 2016-05-13 14:37 GMT+08:00 Pranit Bauva : > On Fri, May 13, 2016 at 11:28 AM, 李本超 wrote: >> git version 2.6.4 (Apple Git-63) >> system version: OS X EI Capitan 10.11.4 >> >> below is the steps: >> $ mkdir test_repo >> $ cd test_repo >> $ git init >> $ echo "hello" > README.md >> $ git commit -a -m 'Add README.md' > > It was my mistake. git-commit -a adds files which are tracked. > Currently README.md is not tracked. So you will have to first use > git-add to add them for tracking. Though while trying out your steps I > used git-add. For further commits one can use -a with git-commit. > >> $ git checkout -b A >> $ echo "world" > README.md >> $ git commit -a -m 'Add one line' > > You are technically not adding a line. You are modifying the previous > line to the updated line. So the contents of the file will be: > "world" > It seems from the further part that you actually wanted to add the > line rather than modifying it. Better to use ">>" instead of ">". ">>" > is used for appending. > >> $ git checkout master >> $ git checkout -b B >> $ echo "world" > README.md >> $ git commit -a -m 'Add one line too' >> $ [midify 'world' line to other things like 'git' using vi] > > I think you mean modify. > >> $ git commit -a -m 'Modify one line' >> >> $ git checkout master >> $ git merge A >> >> $ git checkout B >> $ git rebase master [problem is here, cat README.rd we will get : >> hello and git instead of hello world git] > > The git behavior is quite correct. > When you are on the B branch and you choose to rebase it on the > master, it will apply commits as patches. So it first sees that the > commit on the A branch which is now merged with master ie. "Add one > line" and the commit on the B branch "Add one line too" are doing the > same thing which is removing the line "hello" and adding the line > "world". Then it applies the commit "modify one line" on top of this > which removes the line "world" and adds the line "git". So finally, > README.md will contain only "git". > > Regards, > Pranit Bauva -- Benchao Li School of Electronics Engineering and Computer Science, Peking University Tel:+86-15650713730 Email: libenc...@gmail.com; libenc...@pku.edu.cn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report
It does not warn me in this case. I replayed it again, below is my process: $ mkdir bug_test $ cd bug_test/ $ git init Initialized empty Git repository in /home/libenchao/tmp/bug_test/.git/ $ echo 'hello' > README.md $ git add README.md $ git commit -m 'Add README.md' [master (root-commit) 9cdb3a8] Add README.md 1 file changed, 1 insertion(+) create mode 100644 README.md $ git checkout -b A Switched to a new branch 'A' $ echo 'world' >> README.md $ git commit -a -m 'Add one line' [A 6f0b0a3] Add one line 1 file changed, 1 insertion(+) $ git checkout master Switched to branch 'master' $ git checkout -b B Switched to a new branch 'B' $ echo 'world' >> README.md $ git commit -a -m 'Add one line too' [B d89cf11] Add one line too 1 file changed, 1 insertion(+) $ vim README.md# in this line, I modify line 2 'world' to 'git' $ cat README.md hello git $ git commit -a -m 'Modify one line' [B a674427] Modify one line 1 file changed, 1 insertion(+), 1 deletion(-) $ git checkout master Switched to branch 'master' $ git merge A Updating 9cdb3a8..6f0b0a3 Fast-forward README.md | 1 + 1 file changed, 1 insertion(+) $ git checkout B Switched to branch 'B' $ git rebase master First, rewinding head to replay your work on top of it... Applying: Modify one line $ cat README.md hello git $ 2016-05-13 15:10 GMT+08:00 Pranit Bauva : > On Fri, May 13, 2016 at 12:27 PM, 李本超 wrote: >> Yes, you got the right understanding of my problem. >> >> You are right, the git behavior is quite correct. But I met this >> problem in my practical work: >> >> My colleague added a method but I didn't know. I also added the same method. >> Then I found that I didn't need the method actually, so I deleted it. >> My colleague merged to the master before me. When I wanted to merge, I found >> conflicts with master. And I rebased to current master. And That method was >> deleted finally without any warning or information. > > I am quite sure that there would be an output to show that there are > conflicts and it would be suggesting you to first resolve the > conflicts and there would also be markers in the file like ">>>>>" and > "==" and the file would be marked with "both modified". After you > resolve the conflicts, you can add the file by using git-add and then > "git rebase --continue" to proceed. If you find out that there is some > problem, then you can always use "git rebase --abort" to abort the > rebase process and get to the initial state *perfectly* without any > glitches. > >> Do you think Git should output something to warn the user or I just >> use Git in a wrong way ? > > It does warn. I don't know how it got missed in your case. This is > quite a common problem and even I have faced this quite for quite a > lot of times now and it always did warn me. > >> Thanks. > > I will recommend you reading this article[1]. I know its a bit of a > long read but it will help a lot. > > [1]: http://tedfelix.com/software/git-conflict-resolution.html > > Regards, > Pranit Bauva -- Benchao Li School of Electronics Engineering and Computer Science, Peking University Tel:+86-15650713730 Email: libenc...@gmail.com; libenc...@pku.edu.cn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report
Thanks for your explanation > > The moment where I think you'd like to be notified is when we skipped > doing anything with patch 1. You'd prefer it to say "woah, the other > side of the rebase did the same thing as us". Actually this is the problem where I want to be notified. > But rebase does not do that by default, because the intent of rebase is > that you are rebasing your work on an upstream which might be accepting > part of your work as patches. So it is a feature that rebase says > "already applied upstream -- let's ignore this one". > > I don't think there is a way to ask rebase not to ignore such > already-applied patches. But I'm not sure if there should be, for two > reasons: > > 1. You should consider just using "git merge" to merge the two > branches. That preserves more information about what actually > happened, and would find a conflict in a case like this. > > 2. Even with merging, you cannot assume that the end result is sane. > In your example, there is a textual conflict. But you can easily > come up with other examples where a merge is textually sound, but > has some semantic conflict (e.g., you update the signature of a > function but a colleague adds another call to it using the old > signature). > > You have to examine and test the results of merges for sanity. And > likewise with rebases. > > -Peff > > [1] Actually, rebase does not even try to replay the first patch. When > it generates the list of commits, it ignores any whose "patch-id" is > the same as a commit on the other side. But the end effect is the > same. Your explanation looks reasonable to me. Thanks a lot for your time and patience. And @Pranit Bauva too. By the way, many thanks for maintaining this outstanding software Git. -- Benchao Li School of Electronics Engineering and Computer Science, Peking University Tel:+86-15650713730 Email: libenc...@gmail.com; libenc...@pku.edu.cn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
