git-am annoyance

git-am annoyance

[Sverre Rabbelier]

Heya,

Observe what happens if, on accident, rather than running a alias
(amendall), the 'tab' didn't catch on:
$ git am
^C
$ # ok, now what do I do?
$ git status
# On branch checker-caching
nothing to commit (working directory clean)
$ # looks like everything is ok, great
$ # ... some time later
$ # same thing happens
$ git am
cat: /home/sverre/code/Melange/.git/rebase-apply/next: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/utf8: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/keep: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/threeway: No such
file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/apply-opt: No such
file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/sign: No such file or directory
cat: /home/sverre/code/Melange/.git/rebase-apply/next: No such file or directory
/usr/local/libexec/git-core//git-am: line 319: test: : integer
expression expected
/usr/local/libexec/git-core//git-am: line 326: test: : integer
expression expected
$ # whoops?!

Wouldn't it be nice if "git am" without any arguments just prints a
usage message? Either that, or provides you with a way to bail out? Or
if it'd clean up after itself so that it doesn't crash?

-- 
Cheers,

Sverre Rabbelier

Re: git-am annoyance

[Junio C Hamano]

Sverre Rabbelier <alturin@gmail.com> writes:

> Observe what happens if, on accident, rather than running a alias
> (amendall), the 'tab' didn't catch on:
> $ git am
> ^C

It wants to read from the stdin as "git am < mbox" is a valid usage.

A patch to detect that the input was killed with ^C and clean things up
would be welcome.  Also we may be able to detect "-t 0", too.

> $ # ok, now what do I do?

Here is one thing you could do.

    $ PS1=': $(__git_ps1 "%s"); '
    : master|AM/REBASE; 
    : master|AM/REBASE; git am --abort

But you are right.  We should be able to detect this.

I think it was just people who often use "am" are so used to correctly the
command that the state where no state files are created didn't happen
often and never reported the breakage.

Re: git-am annoyance

[Sverre Rabbelier]

On Tue, Jan 27, 2009 at 23:30, Junio C Hamano <gitster@pobox.com> wrote:
> It wants to read from the stdin as "git am < mbox" is a valid usage.

Ah, ofcourse, that makes sense :).

> A patch to detect that the input was killed with ^C and clean things up
> would be welcome.  Also we may be able to detect "-t 0", too.

What is '-t 0'? How would one detect this in bash?

>> $ # ok, now what do I do?
>
> Here is one thing you could do.
>
>    $ PS1=': $(__git_ps1 "%s"); '
>    : master|AM/REBASE;
>    : master|AM/REBASE; git am --abort

Ugh, I couldn't even get that thing to work :P.

> But you are right.  We should be able to detect this.

That would be nice indeed.

> I think it was just people who often use "am" are so used to correctly the
> command that the state where no state files are created didn't happen
> often and never reported the breakage.

Ok, am glad I reported it then, now it's a known issue at least.

-- 
Cheers,

Sverre Rabbelier

Re: git-am annoyance

[Johannes Schindelin]

Hi,

On Tue, 27 Jan 2009, Sverre Rabbelier wrote:

> What is '-t 0'? How would one detect this in bash?

It detects if file descriptor 0 (stdin) is a terminal.  "man test" to the 
rescue ;-)

Ciao,
Dscho

P.S.: if I hadn't tried exactly that in my valgrind patches recently, I 
would not have known either...