git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Using Origin hashes to improve rebase behavior

From
Johan Herland <johan@herland.net>
Date
Feb 11, 2011, 11:40 UTC
Message-ID
<201102111240.29746.johan@herland.net>
In-Reply-To
<AANLkTikrVPCr92XHirn1u=73eM--T190V-7nbE6fo8ng@mail.gmail.com>
On Friday 11 February 2011, skillzero@gmail.com wrote:
Show 21 quoted lines
> On Thu, Feb 10, 2011 at 1:13 PM, John Wiegley <johnw@boostpro.com> wrote:
> >    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*?
I believe "git rebase" already does exactly what you describe [1].

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...

...Johan
[1]: I tested the above scenario, and got no conflicts:
$ git init
$ FOO=a && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=b && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=c && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ git checkout -b topic
$ FOO=1 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=2 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=3 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=4 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ git checkout master
$ git cherry-pick topic^
$ FOO=d && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ echo e >> 3 && git add 3
$ FOO=e && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=f && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ git checkout topic
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: 1
Applying: 2
Applying: 4
$ # Look, no conflicts.
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: skillzero@gmail.comNext: Jeff King
Message 9 of 14 in “Using Origin hashes to improve rebase behavior”
  1. John WiegleyFeb 10, 2011
  2. Johan HerlandFeb 10, 2011
  3. Jeff KingFeb 10, 2011
  4. John WiegleyFeb 11, 2011
  5. Jeff KingFeb 11, 2011
  6. John WiegleyFeb 11, 2011
  7. Thomas RastFeb 12, 2011
  8. skillzero@gmail.comFeb 11, 2011
  9. Johan HerlandFeb 11, 2011
  10. Jeff KingFeb 11, 2011
  11. Junio C HamanoFeb 11, 2011
  12. Jeff KingFeb 11, 2011
  13. Enrico WeigeltFeb 20, 2011
  14. Dave AbrahamsFeb 21, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.