Re: Using Origin hashes to improve rebase behavior

From: Dave Abrahams <dave@boostpro.com>
Date: Feb 21, 2011, 23:49 UTC
Message-ID: <loom.20110222T004926-60@post.gmane.org>
In-Reply-To: <m21v3fvbix.fsf@hermes.luannocracy.com>

Johan Herland <johan <at> herland.net> writes:

Show 15 quoted lines

> 
> On Friday 11 February 2011, skillzero <at> gmail.com wrote:
> > On Thu, Feb 10, 2011 at 1:13 PM, John Wiegley
> > <johnw <at> boostpro.com> wrote:
>
> > 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].

I can imagine that we could make merges do something similar:

git merge <sources> :=

   Attempt the merge as it works today
   If there are conflicts
       for s in <sources>
            rebase s onto HEAD
       if there are no conflicts
            use the current tree as the result of
                the merge (with the merge's heritage)
            commit
       else
            reset to the conflicted merge state