Andy Zhang <zhgdrx@xxxxxxxxx> writes: > why "git rebase" searching the duplicate patches in <upstream > branch> rather than in <new base branch>? > > hi, all: > > I am reading the help of "git rebase", it says: > "If the upstream branch already contains a change you have made > (e.g., because you mailed a patch which was applied upstream), then > that commit will be skipped. " > > But, because we are applying commits to <new base branch> rather than > to <upstream branch>, I really don't understand why we are searching > the duplicate patches in <upstream branch> rather than in <new base > branch>? It is either a design bug or a documentation bug, or both ;-) I do think it makes sense to skip commits from the branch we are rebasing that have equivalent commits in the upstream, as it is expected that upstream might have already applied/cherry-picked some of the changes you are rebasing, and you do not want to use the same change twice. When we are transplanting a series of commits from an old base to totally unrelated base using the --onto option, e.g. when replaying the contents of 'topic' relative to 'next' down to 'master' in your topology, however, > Old tree is: > > o---o---o---o---o master > \ > o---o---o---o---o next > \ > o---o---o topic it is not necessarily obvious where to stop digging back at. In the above picture where 'master' and 'next' have ancestry relationship, we could try to see if the three commits on 'topic' branch being replayed match any of the commits in next..master range, but when using the --onto option, there does not have to be any relationship between the <upstream> and <new base> (they do not have to share a root commit). So from that point of view, it probably makes sense to default to --no-reapply-cherry-picks when --onto is used, while defaulting --reapply-cherry-picks when --onto is not used.
