Re: git-rebase --abort eats files

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi Madhu,

Johannes Sixt wrote:
> 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