Johannes Schindelin wrote:
Okay, great, that is certainly an improvement over what I thought was
happening. But it won't work if you had to manually resolve a conflict during
the rebase, yes? In that case the diffs would presumably not match.
Correct. There is no automatic way any program could verify that such a
patch is indeed what is already in upstream.
Well, yes there is, in fact: don't forget the existing history like
rebase currently does. Merge doesn't have the same problem. That's kind
of the crux of what I'm proposing here: if you change the implementation
of git's "Don't clutter my history with meaningless merges" feature from
a history-lossy operation (rebase as it stands today) to a display-time
filter (regular merge with an added "I'm just an update" marker) then
this problem evaporates and it becomes safe to clone *any* repository
and pull updates from it, not just ones where the owner is being careful
never to run rebase when there are pending changes.
I think filtering is consistent with the way git does other things.
Renames would be the big example; they are detected after the fact and
dealt with at the point where they're actually relevant to what the user
is doing (merging, etc.) rather than appearing as an explicit part of
the repository's history. Why shouldn't no-op "sync with upstream"
changes work the same way?
Usually, however, this results in a conflict which you have to resolve.
And _you_ do not have a hard time verifying that the patch already went
in, and you just say "git rebase --skip" and the rebasing will continue
_without_ having committed the now obsolete patch.
True enough, but if the computer can retain the information it needs to
do that for me (which it does if I merge instead of rebase) then why
shouldn't it?
-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