Re: [RFC] Replace rebase with filtering

From: Brian Gernhardt <benji@silverinsanity.com>
Date: Jan 16, 2007, 22:31 UTC
Message-ID: <2696299C-A54D-4A7E-BA3B-029C8E4B278D@silverinsanity.com>
In-Reply-To: <eojh8r$9e6$1@sea.gmane.org>

On Jan 16, 2007, at 4:49 PM, Jakub Narebski wrote:

Show 15 quoted lines

> Johannes Schindelin wrote:
>
>> 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.
>
> Unfortunately, at least with git 1.4.4.x, not quite. You have to have
> index clean to do "git rebase --skip", while usually there would be
> conflict when applying patch that is already present some deeper.
>
> I think that is a bug in git-rebase.

Agreed. I tend to "git checkout HEAD -- files" before a "git rebase --skip" to fix that, although I guess "git reset --hard" would work just the same. But by saying "--skip" means "these changes are irrelevant", so it should clean up after itself. It's a definite usability snafu.

I'd put a simple patch to add the reset to git-merge.sh, but I'm not sure I understand what --skip is doing in there with a 30 second peek. Maybe if I get more tuits, I'll do it, but someone more familiar with it can probably do it much faster (and be more certain it's the right thing to do).

~~ Brian