Re: [RFC] Replace rebase with filtering

From: Steven Grimm <koreth@midwinter.com>
Date: Jan 16, 2007, 19:43 UTC
Message-ID: <45AD2AE7.2010908@midwinter.com>
In-Reply-To: <45AD2568.4040408@midwinter.com>

Steven Grimm wrote:

Show 6 quoted lines

> 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