delta/git.git/git-am.sh, branch fc/mergetools-vimdiff3

comments: fix misuses of "nor"

2014-03-31T22:29:27+00:00

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

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

2013-12-05T20:58:21+00:00

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

use @@PERL@@ in built scripts

2013-10-29T19:41:17+00:00

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:12+00:00

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:48+00:00

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

am: return control to caller, for housekeeping

2013-05-13T06:20:07+00:00

We only need to do these two tasks

    git gc --auto
    rm -fr "$dotest"

ourselves if the script was invoked as a standalone program; when
invoked with --rebasing (from git-rebase--am.sh), cascade control back
to the ultimate caller git-rebase.sh to do this for us.

Signed-off-by: Ramkumar Ramachandra 
Signed-off-by: Junio C Hamano

am: tighten a conditional that checks for $dotest

2013-05-13T06:20:07+00:00

In preparation for a later patch that creates $dotest/autostash in
git-rebase.sh before anything else happens, don't assume that the
presence of a $dotest directory implies the existence of the
$dotest/next and $dotest/last files.  Look for them explicitly.

Signed-off-by: Ramkumar Ramachandra 
Signed-off-by: Junio C Hamano

git-am: show the final log message on "Applying:" indicator

2013-03-21T15:09:35+00:00

The "Applying:" message "git am" shows to tell the user which patch
is being applied has traditionally been to help identifying the
input, but we started showing the edited result since f23272f3fd84
(git-am -i: report rewritten title, 2007-12-04), because it was
found more confusing to show the original during an interactive
session.

Treat the modification by the applypatch-msg hook in a similar way
and use the edited result in the progress indication, even though
this is usually not interactive.

Signed-off-by: Simon Ruderich 
Signed-off-by: Junio C Hamano

Merge branch 'jc/fake-ancestor-with-non-blobs'

2013-02-06T00:13:12+00:00

Rebasing the history of superproject with change in the submodule
was broken since v1.7.12.

* jc/fake-ancestor-with-non-blobs:
  apply: diagnose incomplete submodule object name better
  apply: simplify build_fake_ancestor()
  git-am: record full index line in the patch used while rebasing

git-am: record full index line in the patch used while rebasing

2013-02-01T04:30:55+00:00

Earlier, a230949 (am --rebasing: get patch body from commit, not
from mailbox, 2012-06-26) learned to regenerate patch body from the
commit object while rebasing, instead of reading from the rebase-am
front-end.  While doing so, it used "git diff-tree" but without
giving it the "--full-index" option.

This does not matter for in-repository objects; during rebasing, any
abbreviated object name should uniquely identify them.

But we may be rebasing a commit that contains a change to a gitlink,
in which case we usually should not have the object (it names a
commit in the submodule).  A full object name is necessary to later
reconstruct a fake ancestor index for them.

Signed-off-by: Junio C Hamano