From: Madhu <enometh@meer.net>
Date: Tue, 29 Jun 2010 01:23:53 GMT
Subject: Re: git-rebase --abort eats files
Message-ID: <20100629012412.7FDBD1F212@leonis4.robolove.meer.net>
In-Reply-To: <20100628090517.GA8091@debian>

  |Date: Mon, 28 Jun 2010 11:05:17 +0200
  |From: Ramkumar Ramachandra <artagnon@gmail.com>
  |Cc: Madhu <enometh@meer.net>, git@vger.kernel.org
  |Content-Type: text/plain; charset=us-ascii
  |Content-Disposition: inline
  |
  |> 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.

Wrong.  Rebase has to be able to differentaiate between two cases

1. when there is a conflict, and the user is prompted to fix it, and
 then continue with a git-add, git-commit, and git-rebase --continue

and 

2. when the user is given a commit, which he is asked to git-commit
  --amend, and then git-rebase --continue

Rebase is already aware of when each situation occurs.

  |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.

This does not make sense.

--
Madhu