Re: [RFC] Replace rebase with filtering
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 16, 2007, 20:35 UTC
- Message-ID
- <Pine.LNX.4.63.0701162131130.22628@wbgn013.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <45AD2AE7.2010908@midwinter.com>
Hi,
On Tue, 16 Jan 2007, Steven Grimm wrote:
Show 27 quoted lines
> 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.
That is correct, but --ignore-if-in-upstream actually tests the hash of the _diff_, not of the commit. So, if c really introduces the same change as f (i.e. the diffs are identical), git-rebase will ignore f:
a---b---c---d
\
e'---g'Totally untested, of course. But this is what --ignore-if-in-upstream was written for.
Ciao, Dscho