v3, 2 partsgit-am: minor cleanups

When git am is called w/o arguments, w/o a patch on stdin and the user hits ctrl-c, it leaves behind a partially populated $dotest directory. After this commit, it emits usage when called w/o arguments and w/o a patch on stdin.

Noticed by Sverre Rabbelier

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v2: make Junio happy by no longer removing $dotest if git-am is
interupted while mailsplit is running.

 git-am.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Update usage statement to remove a no-longer supported option, and to hide two options (one a no-op, one internal) unless --help-all is used.

Use "test -t 0" instead of "tty -s" to detect when stdin is a terminal. (test -t 0 is used elsewhere in git-am and in other git shell scripts, tty -s is not, and appears to be deprecated by POSIX)

Use "test ..." instead of "[ ... ]" and "die <msg>" instead of "echo <msg>

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v2: mention who deprecated "tty -s" in commit message.

 git-am.sh |   12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)

On Jan 28, 2009, at 3:03 PM, Jay Soffian wrote:

FWIW, I sometimes like to run 'git am', paste in a patch and hit ctrl-d.

I can probably retrain my finger to use 'git am -', but I'm not sure if that works (after this patch)? At least it's not mentioned in the manpage.

- Pieter

On Wed, Jan 28, 2009 at 11:18 AM, Pieter de Bie <pdebie@ai.rug.nl> wrote:

"git am -" doesn't work (before or after this patch), but "cat | git am" will.

j.

Jay Soffian <jaysoffian@gmail.com> writes:

Another approach we've taken in other places to avoid the "Huh?" that triggered this thread is to do something like:

        if there is no argument
        then
		if reading from tty
	        then
	        	echo >&2 "Reading from terminal, waiting for input..."
		fi
                process stdin	
	else
        	for arg
                do
                	process $arg
		done
	fi

Unfortunately, this will invalidate your "check -t 0 and error out" patch, but some people may find it easier to work with and more friendly.

On Wed, Jan 28, 2009 at 1:15 PM, Junio C Hamano <gitster@pobox.com> wrote:

Well perhaps we should just deal w/ctrl-c only and ignore the terminal check altogether.

j.

On Wed, Jan 28, 2009 at 19:26, Jay Soffian <jaysoffian@gmail.com> wrote:

That would suit my needs; as long as doing "git am" and then ^C does not change my worktree and .git directory. Doing a stray "git am --abort" after aborting does not obliterate my worktree as it does now (not nice!), even so, it will change where my branch is currently at!

On Wed, Jan 28, 2009 at 04:18:30PM +0000, Pieter de Bie wrote:

I have to admit, I usually am opposed to this sort of terminal DWIMmery for exactly that reason. But I don't personally ever cut and paste into git-am, so I was trying not to raise a fuss. ;)

-Peff

Jay Soffian <jaysoffian@gmail.com> writes:

Sorry, I think I was misleading. I did not mean that "Also" change was a bad thing to do. It just did not logically belong to this "is it coming from the tty?" issue.

While you are looking at "am", I have a complaint about a very rough and dangerous edge around a relatively new "usability" feature.

A scenario goes like this.

 (1) You have a patch, try to apply it to one existing topic branch

	$ git checkout myTopic
	$ git am some-patch

 (2) You see it does not apply, you realize that the patch is more suited
     for another branch.

	$ git checkout anotherTopic
        $ git am

 (3) It still does not apply, you examine the patch, and find flaws in its
     logic and decide not to apply it at all anywhere.

	$ git am --abort

After this, the tip of anotherTopic is updated to where the tip of myTopic was!

Being able to remove the state directory $GIT_DIR/rebase-apply from the command line is very useful when you want to get a clean slate to run another git-am session, and often it is handy to abort the application of the whole series when you do so (the latter is done by resetting the original branch back to the original commit). But being able to switch branches after starting application of patches from one mailbox is also useful in practice, so at least the latter should not be done blindly when the user asks for --abort. We definitely need some safety here.

Perhaps....

 (1) If --abort is asked for and you are on a branch different from where
     you started your "git am" session from, error out without doing
     anything.

 (2) Add --clean that does what the current --abort does, except for the
     rewinding of the HEAD.

The second one may be useful regardless of the "rough and dangerous edge" issue above. The early parts of the series may be useful and you may want to keep the result from their application, while discarding the remainder of the series.

Hmm?