From: skillzero@gmail.com Date: Fri, 11 Feb 2011 10:02:52 GMT Subject: Re: Using Origin hashes to improve rebase behavior Message-ID: In-Reply-To: On Thu, Feb 10, 2011 at 1:13 PM, John Wiegley wrote: > The following proposal is a check to see if this approach would be sane and > whether someone is already doing similar work.  If not, I offer to implement > this solution. > > THE PROBLEM > > Say I have a master from which I have branched locally, and that this private > branch has four commits: > >    a   b   c >    o---o---o >             \ >              o---o---o---o >              1   2   3   4 > > I then decide to cherry pick commit 3 onto master.  Please believe that my > situation is such that I cannot immediately rebase the private branch to drop > the now-duplicated change.  I end up with this: > >    a   b   c   3' >    o---o---o---o >             \ >              o---o---o---o >              1   2   3   4 > > Later, there is work on master which changes the same lines of code that 3' > has changed.  The commit which changes 3' is e* > >    a   b   c   3'  d   e*  f >    o---o---o---o---o---o---o >             \ >              o---o---o---o >              1   2   3   4 > > At a later date, I want to rebase the private branch onto master.  What will > happen is that the changes in 3 will conflict with the rewritten changes in > e*.  However, I'd like Git to know that 3 was already incorporated at some > earlier time, and *not consider it during the rebase*, since it doesn't need > to. 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*?