From: Brian Gernhardt <benji@silverinsanity.com>
Date: Tue, 16 Jan 2007 22:31:15 GMT
Subject: Re: [RFC] Replace rebase with filtering
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:

> 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