am: handle stray $dotest directory
commitb141f3c9d3220e1e63ca2195df85c392d475baaf
authorRamkumar Ramachandra <artagnon@gmail.com>
Sat, 15 Jun 2013 12:43:11 +0000 (15 18:13 +0530)
committerJunio C Hamano <gitster@pobox.com>
Mon, 17 Jun 2013 15:59:48 +0000 (17 08:59 -0700)
tree0542d766acb0c0031989fb2466309646bc205374
parent587947750bd73544a6a99811f0ddfd64e1ff1445
am: handle stray $dotest directory

The following bug has been observed:

  $ git am  # no input file
  ^C
  $ git am --abort
  Resolve operation not in progress, we are not resuming.

This happens because the following test fails:

  test -d "$dotest" && test -f "$dotest/last" && test -f "$dotest/next"

and the codepath for an "am in-progress" is not executed.  It falls back
to the codepath that treats this as a "fresh execution".  Before
rr/rebase-autostash, this condition was

  test -d "$dotest"

It would incorrectly execute the "normal" am --abort codepath:

  git read-tree --reset -u HEAD ORIG_HEAD
  git reset ORIG_HEAD

by incorrectly assuming that an am is "in progress" (i.e. ORIG_HEAD
etc. was written during the previous execution).

Notice that

  $ git am
  ^C

executes nothing of significance, is equivalent to

  $ mkdir .git/rebase-apply

Therefore, the correct solution is to treat .git/rebase-apply as a
"stray directory" and remove it on --abort in the fresh-execution
codepath.  Also ensure that we're not called with --rebasing from
git-rebase--am.sh; in that case, it is the responsibility of the caller
to handle and stray directories.

While at it, tell the user to run "git am --abort" to get rid of the
stray $dotest directory, if she attempts anything else.

Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am.sh
t/t4150-am.sh