On Tue, Jul 20, 2021 at 6:23 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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 ;-) > It should NOT be a documentation bug, because, in my experiment, I observe that, "git"'s behavior is exactly the same as documentation. So, it should be "work as design". > 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. > >
