On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:
> It does not warn me in this case. I replayed it again, below is my process:
>
> [...setup...]
So after you setup steps you have:
$ git log --decorate --oneline --raw
* a3ce3bc (HEAD -> B) modify
| :100644 100644 94954ab... 23509e0... M README.md
* ef702eb add one line too
| :100644 100644 ce01362... 94954ab... M README.md
| * fa8b99e (master, A) add one line
|/
| :100644 100644 ce01362... 94954ab... M README.md
* cf2103b add readme
:000000 100644 0000000... ce01362... A README.md
Note that B^ (ef702eb) and A (fa8b99e) introduce the exact same change
(moving README.md from ce01362 to 94954ab). And master is at the same
commit as A (due to your fast-forward merge earlier).
So now when you run:
> $ git rebase master
Git will try to replay the commits on master..B on top of master, in
order. Those commits are ef702eb and a3ce3bc (your commit names will
differ, because your name and timestamps will differ).
So it replays the first one, and sees that it the patch is a noop[1];
the tree in master already has the same end state. So we skip the patch.
And then we replay the second one, which applies cleanly.
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".
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.
--
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