Re: Using Origin hashes to improve rebase behavior

From: Jeff King <peff@peff.net>
Date: Feb 11, 2011, 19:03 UTC
Message-ID: <20110211190326.GB29203@sigill.intra.peff.net>
In-Reply-To: <201102111240.29746.johan@herland.net>

On Fri, Feb 11, 2011 at 12:40:29PM +0100, Johan Herland wrote:

Show 10 quoted lines

> > I don't know very much about how git really works so what I'm saying
> > may be dumb, but rather than record where a commit came from, would it
> > be reasonable for rebase to look at the patch-id for each change on
> > the topic branch after the merge base and automatically remove topic
> > branch commits that match that patch-id? So in your example, rebase
> > would check each topic branch commit against 3', d, e*, and f and see
> > that the 3' patch-id is the same as the topic branch 3 and remove
> > topic branch 3 before it gets to e*?
> 
> I believe "git rebase" already does exactly what you describe [1].

Yep. It uses format-patch's "--ignore-if-in-upstream", which computes patch-ids (you can get the same list with "git cherry").

> However, comparing patch-ids stops working when the cherry-pick (3 -> 3') 
> has conflicts. IINM, it is the conflicting cases that John is interested in 
> solving...

Exactly. One other possible solution to this problem would be to somehow make patch-ids handle fuzzy situations better. I doubt it is possible to do that without introducing a lot of false positives, though.

-Peff