Hi,
On Tue, 16 Jan 2007, Steven Grimm wrote:
> 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
-
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