On Thu, Feb 10, 2011 at 1:13 PM, John Wiegley <johnw@xxxxxxxxxxxx> 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*? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html