From: Steven Grimm <koreth@midwinter.com>
Date: Tue, 16 Jan 2007 19:43:35 GMT
Subject: Re: [RFC] Replace rebase with filtering
Message-ID: <45AD2AE7.2010908@midwinter.com>
In-Reply-To: <45AD2568.4040408@midwinter.com>

Steven Grimm wrote:
> Johannes Schindelin wrote:
>> I had the impression that the use of "--ignore-if-in-upstream" in 
>> git-rebase avoids exactly this case: re-applying changes which are 
>> already in upstream.  
> Where's that option documented? The manpage makes no mention of it at 
> all.

Ah, okay, poking around in the git-rebase source, I see you mean that 
git-format-patch is called with that option. Gotcha. The problem is that 
after a rebase, the revisions in question *aren't* in the upstream. 
Here's my understanding of why. Say I have this in my integration 
repository:

a---b---c---d (master)
 \
  e---f---g   (integration)

Now, I rebase the integration branch onto master:

a---b---c---d
             \
              e'---f'---g'

The problem is that, since e' contains all the changes in e *and* in 
b/c/d, it does not have the same SHA1 as the original e revision, nor in 
fact the same hash as any of the revisions in the pre-rebase tree. And 
after rebase succeeds, it wipes the original e, f, and g from the 
history of the integration branch.

When a clone fetches e', f', and g' from this repo and tries to rebase 
onto the integration branch, git-format-patch will think b, c, and d are 
new (correct) but also that e', f', and g' are new. Since they have 
previously unknown hashes and there's no record of the original e, f, 
and g or their relation to the new revisions -- at least, no record that 
gets pulled down to the clone when it fetches -- there's no way for 
git-format-patch to know that it has already applied those changes.

As always, correct me if I'm wrong -- that's my understanding of the 
problem with rebasing in a parent repository.

-Steve