Re: git-rebase --abort eats files

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 28, 2010, 09:05 UTC
Message-ID: <20100628090517.GA8091@debian>
In-Reply-To: <201006262009.30380.j6t@kdbg.org>

Hi Madhu,

Johannes Sixt wrote:

Show 14 quoted lines

> On Samstag, 26. Juni 2010, Madhu wrote:
> > +++ b/git-rebase--interactive.sh
> > @@ -749,6 +749,7 @@ first and then run 'git rebase --continue' again."
> >                         git symbolic-ref HEAD $HEADNAME
> >                         ;;
> >                 esac &&
> > +               git-reset &&
> >                 output git reset --hard $HEAD &&
> >                 rm -rf "$DOTEST"
> >                 exit
> 
> No, it can't be that simple. If rebase stopped due to a conflict on a commit 
> that added new files, then your version of rebase --abort will leave these 
> new files behind as untracked.

Right. The interactive rebase has to be able to differentiate between files that you added to resolve a conflict and files that you added to retain at the end of the rebase -- and the interactive rebase has no information about this. Hence, this problem can't be fixed without explicitly finding out the intent of the user. In my opinion, you should simply stash your changes before aborting the rebase instead of adding files and figuring out some complex way of expressing intent.

-- Ram