threads / discuss / 17397

git-am annoyance

Subject: git-am annoyance

## tl;dr

4 messages between Jan 27, 2009 and Jan 27, 2009.

replies: 3people: 3as markdown or json

Sverre Rabbelier· Jan 27, 2009, 22:07 UTC · lore

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

Junio C Hamano· Jan 27, 2009, 22:30 UTC · re: Sverre Rabbelier · lore

Re: git-am annoyance

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.

Sverre Rabbelier· Jan 27, 2009, 22:37 UTC · re: Junio C Hamano · lore

Re: git-am annoyance

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?

Show 7 quoted lines

>> $ # 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

Johannes Schindelin· Jan 27, 2009, 22:49 UTC · re: Sverre Rabbelier · lore

Re: git-am annoyance

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