Re: [RFC] Replace rebase with filtering

[Steven Grimm <koreth@midwinter.com>]

  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