Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > When rebasing against an upstream that has had many commits since the > original branch was created: > > O -- O -- ... -- O -- O (upstream) > \ > -- O (my-dev-branch) > > it must read the contents of every novel upstream commit, in addition to > the tip of the upstream and the merge base, because "git rebase" > attempts to exclude commits that are duplicates of upstream ones. This > can be a significant performance hit, especially in a partial clone, > wherein a read of an object may end up being a fetch. OK. I presume that we do this by comparing patch IDs? Total disabling would of course is OK as a feature, especially for the first cut, but I wonder if it would be a reasonable idea to use some heuristic to keep the current "filter the same change" feature as much as possible but optimize it by filtering the novel upstream commits without hitting their trees and blobs (I am assuming that you at least are aware of and have the commit objects on the upstream side). The most false-negative-prone approach is just to compare the <author ident, author timestamp> of a candidate upstream commit with what you have---if that author does not appear on my-dev-branch, it is very unlikely that your change has been accepted upstream. Of course, two people who independently discover the same solution is not all that rare, so it does risk false-negative to take too little clue from the commits to compare, but at least it is not worse than what you are proposing here ;-) And if one of your commits on my-dev-branch _might_ be identical to one of the novel upstream ones, at that point, we could dig deeper to actually compute the patch ID by fetching the upstream's tree. That's all totally outside the scope of this patch. It is just a random thought to see if anybody wants to pursue to make the topic even better, possible after it lands. > New in V2: changed parameter name, used Taylor's commit message > suggestions, and used Elijah's documentation suggestions. Hmph, what was it called earlier? My gut reaction without much thinking finds --no-skip-* a bit confusing double-negation and suspect "--[no-]detect-cherry-pick" (which defaults to true for backward compatibility) may feel more natural, but I suspect (I do not recall details of the discussion on v1) it has been already discussed and people found --no-skip-* is OK (in which case I won't object)? I also wonder if --detect-cherry-pick=(yes|no|auto) may give a better end-user experience, with "auto" meaning "do run patch-ID based filtering, but if we know it will be expensive (e.g. the repository is sparsely cloned), please skip it". That way, there may appear other reasons that makes patch-ID computation expensive now or in the fiture, and the users are automatically covered.
