git/git-am.sh, branch v2.1.2

Merge branch 'jl/nor-or-nand-and'

2014-04-08T19:00:28Z

Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"

comments: fix misuses of "nor"

2014-03-31T22:29:27Z

Signed-off-by: Justin Lebar Signed-off-by: Junio C Hamano

git-am.sh: use the $(...) construct for command substitution

2014-03-25T20:43:32Z

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`$.*$`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto Signed-off-by: Junio C Hamano

am: add the --gpg-sign option

2014-02-03T20:12:34Z

Signed-off-by: Nicolas Vigier Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

am: parse options in stuck-long mode

2014-02-03T20:12:18Z

There is no functional change. The reason for this change is to be able to add a new option taking an optional argument. Signed-off-by: Nicolas Vigier Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

git-sh-setup.sh: add variable to use the stuck-long mode

2014-02-03T20:11:10Z

If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse option parsing is done in --stuck-long mode. Signed-off-by: Nicolas Vigier Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'jk/replace-perl-in-built-scripts'

2013-12-05T20:58:21Z

* jk/replace-perl-in-built-scripts: use @@PERL@@ in built scripts

use @@PERL@@ in built scripts

2013-10-29T19:41:17Z

Several of the built shell commands invoke a bare "perl" to perform some one-liners. This will use the first perl in the PATH rather than the one specified by the user's SHELL_PATH. We are not asking these perl invocations to do anything exotic, so typically any old system perl will do; however, in some cases the system perl may have unexpected behavior (e.g., by handling line endings differently). We should err on the side of using the perl the user pointed us to. The downside of this is that on systems with a sane perl setup, we no longer find the perl at runtime, but instead point to a static perl (like /usr/bin/perl). That means we will not handle somebody moving perl without rebuilding git, whereas before we tracked it just fine. This is probably not a big deal, though, as the built perl scripts already suffered from this. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

am: replace uses of --resolved with --continue

2013-06-27T16:37:12Z

git am was previously modified to provide --continue for consistency with rebase, merge etc, and the documentation changed to showing --continue as the primary form. Complete the work by replacing remaining uses of --resolved by --continue, most notably in suggested command reminders. Signed-off-by: Kevin Bracey Signed-off-by: Junio C Hamano

am: handle stray $dotest directory

2013-06-17T15:59:48Z

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 Signed-off-by: Ramkumar Ramachandra Signed-off-by: Junio C Hamano