patcham: handle stray $dotest directory case

The following bug has been observed since rr/rebase-autostash:

  $ 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 am precludes the possibility of a stray $dotest directory existing (when $dotest/{last,next} are not present).

Fix the bug by checking for a stray $dotest directory explicitly and removing it on --abort.

Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 git-am.sh | 5 +++++
 1 file changed, 5 insertions(+)

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Why did the original code sequence that read:

	if test -d "$dotest"
        then
		... handle skip, resolved, abort, because
                ... these can be run ONLY when we know we have
                ... started an "am" session.
		... catch new "git am mbox" invocation and error
                ... out, because that should not be allowed when
                ... we know we have started an "am" session.

had to change its guarding condition to

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

in the first place? Perhaps _that_ guarding condition is what needs to be fixed, by reverting it back to just "does $dotest exist?"

Adding a single case workaround smells like a band-aid to me.

Junio C Hamano wrote:

Like I pointed out earlier, the original codepath is not equipped to handle this case. A "normal" git am --abort runs:

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

blowing away the top commit in the scenario you outlined.

This happens because that codepath incorrectly believes that an am is "in progress". What this means is that it believes that some of the am code actually got executed in the previous run, setting ORIG_HEAD etc. In your scenario

  % git am
  ^C

nothing is executed, and a stray directory is left behind.

If anything, I think the check for $dotest/{next,last} has made the code more robust by correctly verifying that some code did get executed, and that an am is indeed in progress. The bug you have outlined is equivalent to:

  % mkdir .git/rebase-apply
  % git am --abort

Therefore, the fix is to treat it as exactly that: a stray directory that needs to be cleaned up in the codepath that treats it as a "fresh run"; not going through the "normal" am --abort logic and blowing away the top commit.

Makes sense?

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Hmph, when did ORIG_HEAD set, and what commit does it point at?

As "git am" reading from stdin, waiting, hasn't moved HEAD yet at all, I think two things need to happen to fix that:

 (1) at around the call to check_patch_format and split_patches,
     clear ORIG_HEAD (this may have to be done only !$rebasing,
     though).

 (2) safe_to_abort() should make sure ORIG_HEAD exists; otherwise it
     is unsafe.

But that is entirely an independent issue (I am going to agree with you in the end).

That is a correct observation. But it needed a bit of thinking to reach your conclusion that special casing this and handling --abort in a new different codepath is the right solution.

Yes. Or a previous "git am" run lost "$dotest/last" by a bug and then the user asked to "am --abort". Either case, the best you can do is probably to blow away .git/rebase-apply directory.

How would "am --skip", "am --resolved", or "am anothermbox" behave in this "we already have $dotest because the user started one session but killed it" case, which used to be covered by -d $dotest alone but now flows to the other side of the if/else/fi codepath? Do they need a similar treatment, or would they naturally error out as they should?

Junio C Hamano wrote:

By some unrelated previous operation (eg. pull, rebase, merge). The point is that at any point in "normal operation", ORIG_HEAD exists, and usually points to @~N, for some N. If I rm .git/ORIG_HEAD by hand, the am --abort obviously errors out:

  $ git am --abort
  fatal: Not a valid object name ORIG_HEAD
  fatal: ambiguous argument 'ORIG_HEAD': unknown revision or path not
in the working tree.
  Use '--' to separate paths from revisions, like this:
  'git <command> [<revision>...] -- [<file>...]'

Exactly. It might be nice to fix those two things (are there any observed bugs?), but it is entirely orthogonal to our issue.

Yeah, the commit message is lacking.

am --skip and am --resolved will error out, saying "Resolve operation not in progress, we are not resuming". The message needs to be tweaked.

am anothermbox will work just fine, implicitly overwriting the existing $dotest directory. But yeah, we could explicitly remove the directory and allow the mkdir -p to re-create it.

I'll probably work on these follow-ups in the morning.  Thanks for poking.

Ramkumar Ramachandra <artagnon@gmail.com> writes:

OK.

OK. I'll queue this on 'pu', not in 'next' so that it can be rerolled.

Thanks.