Johan Herland <johan <at> herland.net> writes:
>
> 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
--
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