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