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.
Show 29 quoted lines
> 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: libenchao@gmail.com; libenchao@pku.edu.cn