Re: Re* [PATCH v2 2/2] t: add tests for pull --verify-signatures

[Junio C Hamano]

Hans Jerry Illikainen  writes:

> Thanks!  t7612-merge-verify-signatures.sh also lacks cleanup for
> test_must_fail brokenness.  Would you prefer test_when_finished to be
> included in the two patches as a v3?

No, I do not want a v3 as these are already in 'next'.  Just like my
follow-up clean-up you are responding to is [PATCH 3/2], if you want
further work on it, the preferred method from now on is to send in
incremental updates on top of what has already been accepted.


Thanks.

[no subject]

[Friedrich Mayhofer]

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donates the sum of $ 1,000,000.00 to You, Email Me  
personally for more details.
 

Regards.
Friedrich Mayrhofer

Re: [PATCH v2 1/1] check-non-portable-shell.pl: Quoted `wc -l` is not portable

[Eric Sunshine]

On Sat, Dec 16, 2017 at 2:52 PM,   wrote:
> [...]
> Add a check in check-non-portable-shell.pl to find '"' between
> `wc -l` and '=' and hint the user about test_line_count().
>
> Reviewed-by: Johannes Schindelin 
> Signed-off-by: Torsten Bögershausen 
> ---
> diff --git a/t/check-non-portable-shell.pl b/t/check-non-portable-shell.pl
> index 03dc9d2852..fadbb1e5a7 100755
> --- a/t/check-non-portable-shell.pl
> +++ b/t/check-non-portable-shell.pl
> @@ -21,6 +21,7 @@ while (<>) {
> /^\s*declare\s+/ and err 'arrays/declare not portable';
> /^\s*[^#]\s*which\s/ and err 'which is not portable (please use 
> type)';
> /\btest\s+[^=]*==/ and err '"test a == b" is not portable (please use 
> =)';
> +   /\bwc -l.*"\s*=/ and err '`"$(wc -l)"` is not portable, please use 
> test_line_count';

Nit: Every other "please use" suggestion is parenthesized; for
consistency, this probably ought to be, as well.

> /\bexport\s+[A-Za-z0-9_]*=/ and err '"export FOO=bar" is not portable 
> (please use FOO=bar && export FOO)';

Re: [PATCH v2 8/8] travis-ci: only print test failures if there are

[Eric Sunshine]

On Sat, Dec 16, 2017 at 5:48 PM, SZEDER Gábor  wrote:
> On Sat, Dec 16, 2017, Eric Sunshine  wrote:
>> I'd think you'd want to capture the result of the expansion of
>> t/test-result/*.exit as a string and compare that instead.
>
> I'm not sure how the result of the expansion could be captured in the
> shell, because the shell performs the expansion only just before it
> executes a command.  And if we do have to execute a command anyway,
> then we can simply rely on the command exiting with an error code upon
> not finding any files, and there's no need to capture the expansion or
> for the comparison for that matter.
> So I propose this updated patch, using 'ls' instead of 'test':

To capture the expansion as a string, I was thinking along the lines of:

x=$(echo t/test-results/*.exit)

but that's a minor point. Checking the explicit exit code of a
command, as you suggest, is probably cleaner.

Re: [PATCH v2 8/8] travis-ci: only print test failures if there are

[SZEDER Gábor]

> On Sat, Dec 16, 2017 at 7:58 AM, SZEDER G=C3=A1bor  w=
> rote:

> > +if test t/test-results/*.exit =3D "t/test-results/*.exit"
> 
> Isn't the above going to cause 'test' to error out?
>
> $ mkdir -p t/test-results
> $ >t/test-results/a.exit
> $ >t/test-results/b.exit
> $ test t/test-results/*.exit =3D 't/test-results/*.exit'
> -bash: test: too many arguments

Indeed it does, though Travis CI's /bin/sh gives a different error
message.  Thanks for pointin it out, I didn't notice the error msg,
because the script as a whole still did the right thing and then I
didn't look close enough.

> I'd think you'd want to capture the result of the expansion of
> t/test-result/*.exit as a string and compare that instead.

I'm not sure how the result of the expansion could be captured in the
shell, because the shell performs the expansion only just before it
executes a command.  And if we do have to execute a command anyway,
then we can simply rely on the command exiting with an error code upon
not finding any files, and there's no need to capture the expansion or
for the comparison for that matter.

So I propose this updated patch, using 'ls' instead of 'test':


  -- >8 --

Subject: [PATCH v2.1 8/8] travis-ci: only print test failures if there are test 
results available

When a build job running the test suite fails, our
'ci/print-test-failures.sh' script scans all 't/test-results/*.exit'
files to find failed tests and prints their verbose output.  However,
if a build job were to fail before it ever gets to run the test suite,
then there will be no files to match the above pattern and the shell
will take the pattern literally, resulting in errors like this in the
trace log:

  cat: t/test-results/*.exit: No such file or directory
  
  t/test-results/*.out...
  
  cat: t/test-results/*.out: No such file or directory

Check upfront and proceed only if there are any such files present.

Signed-off-by: SZEDER Gábor 
---
 ci/print-test-failures.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh
index f757e616c..b4a62ef98 100755
--- a/ci/print-test-failures.sh
+++ b/ci/print-test-failures.sh
@@ -8,6 +8,12 @@
 # Tracing executed commands would produce too much noise in this script.
 set +x
 
+if ! ls t/test-results/*.exit >/dev/null 2>/dev/null
+then
+   echo "Build job failed before the tests could have been run"
+   exit
+fi
+
 for TEST_EXIT in t/test-results/*.exit
 do
if [ "$(cat "$TEST_EXIT")" != "0" ]
-- 
2.15.1.429.ga000dd9c7

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

[brian m. carlson]

On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote:
> Jonathan Nieder  writes:
> > As for "git config --global", I think the best thing would be to split
> > it into two options: something like "git config --user" and "git
> > config --xdg-user".  That way, it is unambiguous which configuration
> > file the user intends to inspect or modify.  When a user calls "git
> > config --global" and both files exist, it could warn that the command
> > is ambiguous.
> >
> > Thoughts?
> 
> I actually thought that the plan was "you either have this, or the
> other one, never both at the same time" (and I think those who
> pushed the XDG thing in to the system made us favor it over the
> traditional one).  So as long as --global updates the one that
> exists, and updates XDG one when both or neither do, I think we
> should be OK.  And from that viewpoint, we definitely do not want
> two kinds of --global to pretend as if we support use of both at the
> same time.

Sorry for coming late to the discussion, but I actually use both.

~/.gitconfig is checked into my Git repo for my home directory and
contains settings I preserve across all systems, and the XDG dir is not
checked in and contains per-system settings (currently just
commit.gpgsign).  On my main systems I have a key and sign commits; if
it's just some server I log into, I don't.

Now, I don't use git config to set options, so I'm happy as long as git
config can read both, which it does.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

GREETINGS BELOVED

[mis.sbort...@ono.com]

GREETINGS BELOVED

I AM BORTE ,I WAS DIAGNOSE WITH OVARIAN CANCER,WHICH DOCTORS HAVE 
CONFIRMED THAT I HAVE ONLY FEW WEEKS TO LIVE, SO I HAVE DECIDED TO 
DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH 
YOU AND YOUR HELP .PLEASE KINDLY REPLY ME ONLY ON MY EMAIL ADDRESS HERE 
SO THAT YOUR MESSAGE WILL GET TO ME (misbotteogot...@gmail.com)REPLY AS 
SOON AS POSIBLE TO ENABLE ME GIVE YOU MORE INFORMATION ABOUT MYSELF AND 
HOW TO GO ABOUT IT.  
 
 
THANKS

MISS BORTE

[PATCH v2 1/1] check-non-portable-shell.pl: Quoted `wc -l` is not portable

[tboegi]

From: Torsten Bögershausen 

wc -l was used to count the number if lines in test scripts.
$ wc -l Makefile
gives a line like this:
105 Makefile
while Mac OS has 4 leading spaces:
 105 Makefile

And this means that shell expressions like
test "$(wc -l 

[PATCH] l10n: de.po: improve messages when a branch starts to track another ref

[Ralf Thielow]

Signed-off-by: Ralf Thielow 
---
 po/de.po | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/po/de.po b/po/de.po
index 400262625..00ffd8c41 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1070,42 +1070,42 @@ msgstr "Branch %s kann nicht sein eigener 
Upstream-Branch sein."
 #: branch.c:93
 #, c-format
 msgid "Branch '%s' set up to track remote branch '%s' from '%s' by rebasing."
-msgstr "Branch '%s' konfiguriert zum Folgen von Remote-Branch '%s' von '%s' 
durch Rebase."
+msgstr "Branch '%s' folgt nun Remote-Branch '%s' von '%s' durch Rebase."
 
 #: branch.c:94
 #, c-format
 msgid "Branch '%s' set up to track remote branch '%s' from '%s'."
-msgstr "Branch '%s' konfiguriert zum Folgen von Remote-Branch '%s' von '%s'."
+msgstr "Branch '%s' folgt nun Remote-Branch '%s' von '%s'."
 
 #: branch.c:98
 #, c-format
 msgid "Branch '%s' set up to track local branch '%s' by rebasing."
-msgstr "Branch '%s' konfiguriert zum Folgen von lokalem Branch '%s' durch 
Rebase."
+msgstr "Branch '%s' folgt nun lokalem Branch '%s' durch Rebase."
 
 #: branch.c:99
 #, c-format
 msgid "Branch '%s' set up to track local branch '%s'."
-msgstr "Branch '%s' konfiguriert zum Folgen von lokalem Branch '%s'."
+msgstr "Branch '%s' folgt nun lokalem Branch '%s'."
 
 #: branch.c:104
 #, c-format
 msgid "Branch '%s' set up to track remote ref '%s' by rebasing."
-msgstr "Branch '%s' konfiguriert zum Folgen von Remote-Referenz '%s' durch 
Rebase."
+msgstr "Branch '%s' folgt nun Remote-Referenz '%s' durch Rebase."
 
 #: branch.c:105
 #, c-format
 msgid "Branch '%s' set up to track remote ref '%s'."
-msgstr "Branch '%s' konfiguriert zum Folgen von Remote-Referenz '%s'."
+msgstr "Branch '%s' folgt nun Remote-Referenz '%s'."
 
 #: branch.c:109
 #, c-format
 msgid "Branch '%s' set up to track local ref '%s' by rebasing."
-msgstr "Branch '%s' konfiguriert zum Folgen von lokaler Referenz '%s' durch 
Rebase."
+msgstr "Branch '%s' folgt nun lokaler Referenz '%s' durch Rebase."
 
 #: branch.c:110
 #, c-format
 msgid "Branch '%s' set up to track local ref '%s'."
-msgstr "Branch '%s' konfiguriert zum Folgen von lokaler Referenz '%s'."
+msgstr "Branch '%s' folgt nun lokaler Referenz '%s'."
 
 #: branch.c:119
 msgid "Unable to write upstream branch configuration"
-- 
2.15.1.504.g5279b8010

'git format-patch --summary' seems to be turning off the stat

[Kaartic Sivaraam]

The documentation for "--summary" option in the format-patch Doc states, 
--summary Output a condensed summary of extended header information such 
as creations, renames and mode changes. It doesn't state anything about 
turning of the stat. Why does the stat get turned off when "--summary" 
option is used along with "git format-patch" ? Note: I do see that 
"--summary" is a diff-option but does that mean we should't be printing 
stat information in the patch when the user didn't mention "--no-stat"? 
Yeah, "git format-patch  --summary --stat" does bring back the 
stat. --- Kaartic

Re: Apparent bug in 'git stash push ' loses untracked files

[Junio C Hamano]

Thomas Gummerer  writes:

> Maybe the best solution would be to introduce 'git reset --hard --
> ', or maybe someone who knows shell programming a little
> better than me has an idea? 
>
> diff --git a/git-stash.sh b/git-stash.sh
> index 1114005ce2..01bf74015e 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -322,10 +322,15 @@ push_stash () {
>  
> if test $# != 0
> then
> +   git ls-files -z >"$(git rev-parse 
> --git-dir)"/stash-to-remove
> git reset -q -- "$@"
> git ls-files -z --modified -- "$@" |
> git checkout-index -z --force --stdin
> -   git clean --force -q -d -- "$@"
> +   while read -r -d '' to_delete
> +   do
> +   git clean --force -q -d -- "$to_delete"
> +   done <"$(git rev-parse --git-dir)"/stash-to-remove
> +   rm "$(git rev-parse --git-dir)"/stash-to-remove
> else
> git reset --hard -q
> fi

Hmph.  I personally did not care (nor use) pathspec limited stash
creation, so I admit that I do not offhand know what this code
(before or after the above fix) is trying to do, even though it has
been in our tree for some time X-<.  But judging from the fact that
the other side is a mere "git reset --hard" (for the whole tree), I
guess for each and every path in the index and/or in the HEAD that
match pathspec "$@", you are trying to

 - remove it from the index if it is not in HEAD;

 - add it to the index if it is not in the index but is in HEAD; or

 - reset the index to the version in HEAD if it is in the index.

and then match the working tree version to that of the index?

I am not convinced that "git reset --hard -- " is a good
UI [*1*] but I agree that a low level facility that does these would
be quite helpful to implement the then-clause of the above.

But I suspect that you do not have to do shell "logic" nor low-level
plumbing update in this case.  Would the attached work?

[Footnote]

*1* Primarily because "git reset [] -- " that
already exists is not a good UI.  The remainder of "git reset"
is about repointing the HEAD, and the various operation modes
are there to adjust the index and the working tree to the
updated HEAD depending on why the user wants to repoint the HEAD
in the first place.  On the other hand, the pathspec limited
"reset" is all about affecting the index without moving the HEAD
and operation modes, if --hard is also taught not to reject
pathspec, will become "do we do index-only or do we do both?"

But updating the index and the working tree is what "git
checkout [] -- " is for, and the "git reset
[] -- " should have been "checkout --cached
[] -- " (and the "reset --hard" equivalent
should be the "default" for checkout).

There is a small glitch in the current behaviour of "checkout --
" to complicate the above vision, but assuming that it
is surmountable, and if we were going to update the UI for
consistency along the above line, then I do not mind making "git
checkout" solely for "checking out paths" and adding a different
subcommannd to "checking out a branch to work on".

"reset." is about resetting the HEAD and "reset
[] -- " is about resetting the index, which
is the same duality some people complain about "git checkout"
that is both about checking out the paths and checking out a
branch to work on.  Adding more mode(s) to "git reset" that
makes the command not about repointing the HEAD is piling more
on top.

The "small glitch" is that "checkout  -- "
is defined as an overlay operation---take the current index (and
the working tree), then for each (path, contents) in 
that match the , add it in if path does not exist in
the current index, or replace if path does.  If we have a path
in the index that match , and that path does not exist
in , "checkout  -- " does not
remove that path from the index.

So even the index+working tree mode (which is how "reset --hard"
would want to work) may need to take a new option.  Between two
modes of "checkout  -- " that allows
deletion, "--index" would be the one that works on both the
index and the working tree, and "--cached" would be the one that
works only on the index (this follows gitcli convention that is
used by existing commands), and the current "overlay" mode will
stay to be the default, at least until we know that the "--index"
mode should become the default and decide to transition.




---

 git-stash.sh |  5 ++---
 t/t3903-stash.sh | 16 
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 1114005ce2..a979bfb665 100755
--- a/git-stash.sh
+++ 

Re: [PATCH v2 8/8] travis-ci: only print test failures if there are test results available

[Eric Sunshine]

On Sat, Dec 16, 2017 at 7:58 AM, SZEDER Gábor  wrote:
> When a build job running the test suite fails, our
> 'ci/print-test-failures.sh' script scans all 't/test-results/*.exit'
> files to find failed tests and prints their verbose output.  However,
> if a build job were to fail before it ever gets to run the test suite,
> then there will be no files to match the above pattern and the shell
> will take the pattern literally, resulting in errors like this in the
> trace log:
>
>   cat: t/test-results/*.exit: No such file or directory
>   
>   t/test-results/*.out...
>   
>   cat: t/test-results/*.out: No such file or directory
>
> Check upfront and proceed only if there are any such files present.
>
> Signed-off-by: SZEDER Gábor 
> ---
> diff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh
> @@ -8,6 +8,12 @@
> +if test t/test-results/*.exit = "t/test-results/*.exit"

Isn't the above going to cause 'test' to error out?

$ mkdir -p t/test-results
$ >t/test-results/a.exit
$ >t/test-results/b.exit
$ test t/test-results/*.exit = 't/test-results/*.exit'
-bash: test: too many arguments

I'd think you'd want to capture the result of the expansion of
t/test-result/*.exit as a string and compare that instead.

> +then
> +   echo "Build job failed before the tests could have been run"
> +   exit
> +fi

Re: [PATCH v2 1/8] travis-ci: use 'set -x' in select 'ci/*' scripts for extra tracing

[Johannes Schindelin]

Hi Gábor,

On Sat, 16 Dec 2017, SZEDER Gábor wrote:

> While the build logic was embedded in our '.travis.yml', Travis CI
> used to produce a nice trace log including all commands executed in
> those embedded scriptlets.  Since 657343a60 (travis-ci: move Travis CI
> code into dedicated scripts, 2017-09-10), however, we only see the
> name of the dedicated scripts, but not what those scripts are actually
> doing, resulting in a less useful trace log about e.g. installing
> dependencies.  A patch later in this series will move setting
> environment variables from '.travis.yml' to 'ci/lib-travisci.sh', so
> not even those will be included in the trace log.  Unrelated to
> 657343a60, 'ci/test-documentation.sh' runs a bunch of 'test -s '
> checks which would fail quietly if something were wrong, leaving no
> clue about which one of those checks triggered the failure.
> 
> Use 'set -x' in 'ci/lib-travisci.sh' to get more detailed trace log
> about the commands executed in the 'ci/*' scripts.  Use it in
> 'ci/run-linux32-build.sh' as well, which is run in a Docker container
> and therefore doesn't source 'ci/lib-travisci.sh'.  The secret token
> used for the Windows builds is specified as an encrypted environment
> variable in git/git repository settings on Travis CI and it's redacted
> in the trace logs even with 'set -x'.  However, disable this tracing
> in 'ci/print-test-failures.sh', as it produces far too much noise in
> the output of that script.

ACK,
Dscho

Merry Christmas

[Mrs Alice Walton]

my name is Mrs. Alice Walton, a business woman an America Citizen and the 
heiress to the fortune of Walmart stores, born October 7, 1949. I have a 
mission for you worth $100,000,000.00(Hundred Million United State Dollars) 
which I intend using for CHARITY

I wait for your prompt response.

[SAM AZADA]

Good day,

I am Mr. Sam Azada from Burkina Faso  a Minister confide on me to look
for foreign partner who will assist him to invest the sum of  Fifty
Million  Dollars  ($50,000,000) in your country.

He has investment interest in mining, exotic properties for commercial
resident, development properties, hotels and any other viable
investment opportunities in your country based on your recommendation
will be highly welcomed.

Hence your co -operation is highly needed to actualize this investment project

I wait for your prompt response.

Sincerely yours

Mr Sam Azada.

Urgent Message

[Western Union]

Dear Western Union Customer,
 
You have been awarded with the sum of $250,000 USD by our office, as one of our 
customers who use Western Union in their daily business transaction. This award 
was been selected through the internet, where your e-mail address was indicated 
and notified. Please provide Mr. James Udo with the following details listed 
below so that your fund will be remited to you through Western Union.
 
1. Name:
2. Address:
3. Country:
4. Phone Number:
5. Occupation:
6. Sex:
7. Age:
 
Mr. James Udo E-mail: westerrnunion2...@outlook.com
 
As soon as these details are received and verified, your fund will be 
transferred to you.Thank you, for using western union.

[PATCH v2 8/8] travis-ci: only print test failures if there are test results available

[SZEDER Gábor]

When a build job running the test suite fails, our
'ci/print-test-failures.sh' script scans all 't/test-results/*.exit'
files to find failed tests and prints their verbose output.  However,
if a build job were to fail before it ever gets to run the test suite,
then there will be no files to match the above pattern and the shell
will take the pattern literally, resulting in errors like this in the
trace log:

  cat: t/test-results/*.exit: No such file or directory
  
  t/test-results/*.out...
  
  cat: t/test-results/*.out: No such file or directory

Check upfront and proceed only if there are any such files present.

Signed-off-by: SZEDER Gábor 
---
 ci/print-test-failures.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh
index f757e616c..1a3d74d47 100755
--- a/ci/print-test-failures.sh
+++ b/ci/print-test-failures.sh
@@ -8,6 +8,12 @@
 # Tracing executed commands would produce too much noise in this script.
 set +x
 
+if test t/test-results/*.exit = "t/test-results/*.exit"
+then
+   echo "Build job failed before the tests could have been run"
+   exit
+fi
+
 for TEST_EXIT in t/test-results/*.exit
 do
if [ "$(cat "$TEST_EXIT")" != "0" ]
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 7/8] travis-ci: save prove state for the 32 bit Linux build

[SZEDER Gábor]

This change follows suit of 6272ed319 (travis-ci: run previously
failed tests first, then slowest to fastest, 2016-01-26), which did
this for the Linux and OSX build jobs.  Travis CI build jobs run the
tests parallel, which is sligtly faster when tests are run in slowest
to fastest order, shortening the overall runtime of this build job by
about a minute / 10%.

Note, that the 32 bit Linux build job runs the tests suite in a Docker
container and we have to share the Travis CI cache directory with the
container as a second volume.  Otherwise we couldn't use a symlink
pointing to the prove state file in the cache directory, because
that's outside of the directory hierarchy accessible from within the
container.

Signed-off-by: SZEDER Gábor 
---
 ci/run-linux32-build.sh  | 1 +
 ci/run-linux32-docker.sh | 1 +
 2 files changed, 2 insertions(+)

diff --git a/ci/run-linux32-build.sh b/ci/run-linux32-build.sh
index a8518eddf..c19c50c1c 100755
--- a/ci/run-linux32-build.sh
+++ b/ci/run-linux32-build.sh
@@ -27,6 +27,7 @@ test -z $HOST_UID || (CI_USER="ci" && useradd -u $HOST_UID 
$CI_USER) &&
 # Build and test
 linux32 --32bit i386 su -m -l $CI_USER -c '
 cd /usr/src/git &&
+ln -s /tmp/travis-cache/.prove t/.prove &&
 make --jobs=2 &&
 make --quiet test
 '
diff --git a/ci/run-linux32-docker.sh b/ci/run-linux32-docker.sh
index 0edf63acf..3a8b2ba42 100755
--- a/ci/run-linux32-docker.sh
+++ b/ci/run-linux32-docker.sh
@@ -19,5 +19,6 @@ docker run \
--env GIT_TEST_OPTS \
--env GIT_TEST_CLONE_2GB \
--volume "${PWD}:/usr/src/git" \
+   --volume "${HOME}/travis-cache:/tmp/travis-cache" \
daald/ubuntu32:xenial \
/usr/src/git/ci/run-linux32-build.sh $(id -u $USER)
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 5/8] travis-ci: don't install default addon packages for the 32 bit Linux build

[SZEDER Gábor]

The 32 bit Linux build job compiles Git and runs the test suite in a
Docker container, while the additional packages (apache2, git-svn,
language-pack-is) are installed on the host, therefore don't have
any effect and are unnecessary.

Signed-off-by: SZEDER Gábor 
---
 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis.yml b/.travis.yml
index 7c9aa0557..4684b3f4f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -42,6 +42,7 @@ matrix:
 - env: jobname=Linux32
   os: linux
   compiler:
+  addons:
   services:
 - docker
   before_install:
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 6/8] travis-ci: don't install 'language-pack-is' package

[SZEDER Gábor]

Ever since we have started to use Travis CI in 522354d70 (Add Travis
CI support, 2015-11-27), our 64 bit Linux build jobs install the
'languate-pack-is' package.  That commit doesn't discuss why it was
deemed necessary back then, but Travis CI can build and test Git
without that package just fine, even that commit introducing Travis CI
support.

Signed-off-by: SZEDER Gábor 
---
 .travis.yml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 4684b3f4f..ea11b5af6 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -17,7 +17,6 @@ compiler:
 addons:
   apt:
 packages:
-- language-pack-is
 - git-svn
 - apache2
 
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 4/8] travis-ci: set GIT_TEST_HTTPD in 'ci/lib-travisci.sh'

[SZEDER Gábor]

Commit 657343a60 (travis-ci: move Travis CI code into dedicated
scripts, 2017-09-10) converted '.travis.yml's default 'before_install'
scriptlet to the 'ci/install-dependencies.sh' script, and while doing
so moved setting GIT_TEST_HTTPD=YesPlease for the 64-bit GCC and Clang
Linux build jobs to that script.  This is wrong for two reasons:

 - The purpose of that script is, as its name suggests, to install
   dependencies, not to set any environment variables influencing
   which tests should be run (though, arguably, this was already an
   issue with the original 'before_install' scriptlet).

 - Setting the variable has no effect anymore, because that script is
   run in a separate shell process, and the variable won't be visible
   in any of the other scripts, notably in 'ci/run-tests.sh'
   responsible for, well, running the tests.

Luckily, this didn't have a negative effect on our Travis CI build
jobs, because GIT_TEST_HTTPD is a tri-state variable defaulting to
"auto" and a functioning web server was installed in those Linux build
jobs, so the httpd tests were run anyway.

Apparently the httpd tests run just fine without GIT_TEST_HTTPD being
set, therefore we could simply remove this environment variable.
However, if a bug were to creep in to change the Travis CI build
environment to run the tests as root or to not install Apache, then
the httpd tests would be skipped and the build job would still
succeed.  We would only notice if someone actually were to look
through the build job's trace log; but who would look at the trace log
of a successful build job?!

Since httpd tests are important, we do want to run them and we want to
be loudly reminded if they can't be run.  Therefore, move setting
GIT_TEST_HTTPD=YesPlease for the 64-bit GCC and Clang Linux build jobs
to 'ci/lib-travisci.sh' to ensure that the build job fails when the
httpd tests can't be run.  (We could set it in 'ci/run-tests.sh' just
as well, but it's better to keep all environment variables in one
place in 'ci/lib-travisci.sh'.)

Signed-off-by: SZEDER Gábor 
---
 ci/install-dependencies.sh | 2 --
 ci/lib-travisci.sh | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 468788566..75a9fd247 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -10,8 +10,6 @@ 
LFSWHENCE=https://github.com/github/git-lfs/releases/download/v$LINUX_GIT_LFS_VE
 
 case "$jobname" in
 linux-clang|linux-gcc)
-   export GIT_TEST_HTTPD=YesPlease
-
mkdir --parents "$P4_PATH"
pushd "$P4_PATH"
wget --quiet "$P4WHENCE/bin.linux26x86_64/p4d"
diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
index c5c5cb1bf..348fe3c3c 100755
--- a/ci/lib-travisci.sh
+++ b/ci/lib-travisci.sh
@@ -42,6 +42,8 @@ export GIT_TEST_CLONE_2GB=YesPlease
 
 case "$jobname" in
 linux-clang|linux-gcc)
+   export GIT_TEST_HTTPD=YesPlease
+
# The Linux build installs the defined dependency versions below.
# The OS X build installs the latest available versions. Keep that
# in mind when you encounter a broken OS X build!
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 3/8] travis-ci: move setting environment variables to 'ci/lib-travisci.sh'

[SZEDER Gábor]

Our '.travis.yml's 'env.global' section sets a bunch of environment
variables for all build jobs, though none of them actually affects all
build jobs.  It's convenient for us, and in most cases it works just
fine, because irrelevant environment variables are simply ignored.

However, $GIT_SKIP_TESTS is an exception: it tells the test harness to
skip the two test scripts that are prone to occasional failures on
OSX, but as it's set for all build jobs those tests are not run in any
of the build jobs that are capable to run them reliably, either.

Therefore $GIT_SKIP_TESTS should only be set in the OSX build jobs,
but those build jobs are included in the build matrix implicitly (i.e.
by combining the matrix keys 'os' and 'compiler'), and there is no way
to set an environment variable only for a subset of those implicit
build jobs.  (Unless we were to add new scriptlets to '.travis.yml',
which is exactly the opposite direction that we took with commit
657343a60 (travis-ci: move Travis CI code into dedicated scripts,
2017-09-10)).

So move setting $GIT_SKIP_TESTS to 'ci/lib-travisci.sh', where it can
trivially be set only for the OSX build jobs.

Furthermore, move setting all other environment variables from
'.travis.yml' to 'ci/lib-travisci.sh', too, because a couple of
environment variables are already set there, and this way all
environment variables will be set in the same place.  All the logic
controlling our builds is already in the 'ci/*' scripts anyway, so
there is really no good reason to keep the environment variables
separately.

Signed-off-by: SZEDER Gábor 
---
 .travis.yml| 18 +-
 ci/lib-travisci.sh | 21 +
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 88435e11c..7c9aa0557 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -21,25 +21,9 @@ addons:
 - git-svn
 - apache2
 
-env:
-  global:
-- DEVELOPER=1
-# The Linux build installs the defined dependency versions below.
-# The OS X build installs the latest available versions. Keep that
-# in mind when you encounter a broken OS X build!
-- LINUX_P4_VERSION="16.2"
-- LINUX_GIT_LFS_VERSION="1.5.2"
-- DEFAULT_TEST_TARGET=prove
-- GIT_PROVE_OPTS="--timer --jobs 3 --state=failed,slow,save"
-- GIT_TEST_OPTS="--verbose-log"
-- GIT_TEST_CLONE_2GB=YesPlease
-# t9810 occasionally fails on Travis CI OS X
-# t9816 occasionally fails with "TAP out of sequence errors" on Travis CI 
OS X
-- GIT_SKIP_TESTS="t9810 t9816"
-
 matrix:
   include:
-- env: jobname=GETTEXT_POISON GETTEXT_POSION=YesPlease
+- env: jobname=GETTEXT_POISON
   os: linux
   compiler:
   addons:
diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
index 4b3c5fdd0..c5c5cb1bf 100755
--- a/ci/lib-travisci.sh
+++ b/ci/lib-travisci.sh
@@ -34,10 +34,31 @@ then
jobname="$TRAVIS_OS_NAME-$CC"
 fi
 
+export DEVELOPER=1
+export DEFAULT_TEST_TARGET=prove
+export GIT_PROVE_OPTS="--timer --jobs 3 --state=failed,slow,save"
+export GIT_TEST_OPTS="--verbose-log"
+export GIT_TEST_CLONE_2GB=YesPlease
+
 case "$jobname" in
 linux-clang|linux-gcc)
+   # The Linux build installs the defined dependency versions below.
+   # The OS X build installs the latest available versions. Keep that
+   # in mind when you encounter a broken OS X build!
+   export LINUX_P4_VERSION="16.2"
+   export LINUX_GIT_LFS_VERSION="1.5.2"
+
P4_PATH="$(pwd)/custom/p4"
GIT_LFS_PATH="$(pwd)/custom/git-lfs"
export PATH="$GIT_LFS_PATH:$P4_PATH:$PATH"
;;
+osx-clang|osx-gcc)
+   # t9810 occasionally fails on Travis CI OS X
+   # t9816 occasionally fails with "TAP out of sequence errors" on
+   # Travis CI OS X
+   export GIT_SKIP_TESTS="t9810 t9816"
+   ;;
+GETTEXT_POISON)
+   export GETTEXT_POISON=YesPlease
+   ;;
 esac
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 2/8] travis-ci: introduce a $jobname variable for 'ci/*' scripts

[SZEDER Gábor]

A couple of 'ci/*' scripts are shared between different build jobs:
'ci/lib-travisci.sh', being a common library, is sourced from almost
every script, while 'ci/install-dependencies.sh', 'ci/run-build.sh'
and 'ci/run-tests.sh' are shared between the "regular" GCC and Clang
Linux and OSX build jobs, and the latter two scripts are used in the
GETTEXT_POISON Linux build job as well.

Our builds could benefit from these shared scripts being able to
easily tell which build job they are taking part in.  Now, it's
already quite easy to tell apart Linux vs OSX and GCC vs Clang build
jobs, but it gets trickier with all the additional Linux-based build
jobs included explicitly in the build matrix.

Unfortunately, Travis CI doesn't provide much help in this regard.
The closest we've got is the $TRAVIS_JOB_NUMBER variable, the value of
which is two dot-separated integers, where the second integer
indicates a particular build job.  While it would be possible to use
that second number to identify the build job in our shared scripts, it
doesn't seem like a good idea to rely on that:

  - Though the build job numbering sequence seems to be stable so far,
Travis CI's documentation doesn't explicitly states that it is
indeed stable and will remain so in the future.  And even if it
were stable,

  - if we were to remove or insert a build job in the middle, then the
job numbers of all subsequent build jobs would change accordingly.

So roll our own means of simple build job identification and introduce
the $jobname environment variable in our builds, setting it in the
environments of the explicitly included jobs in '.travis.yml', while
constructing one in 'ci/lib-travisci.sh' as the combination of the OS
and compiler name for the GCC and Clang Linux and OSX build jobs.  Use
$jobname instead of $TRAVIS_OS_NAME in scripts taking different
actions based on the OS and build job (when installing P4 and Git LFS
dependencies and including them in $PATH).  The following two patches
will also rely on $jobname.

Signed-off-by: SZEDER Gábor 
---
 .travis.yml| 10 +-
 ci/install-dependencies.sh |  6 +++---
 ci/lib-travisci.sh |  9 +++--
 3 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 281f101f3..88435e11c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -39,12 +39,12 @@ env:
 
 matrix:
   include:
-- env: GETTEXT_POISON=YesPlease
+- env: jobname=GETTEXT_POISON GETTEXT_POSION=YesPlease
   os: linux
   compiler:
   addons:
   before_install:
-- env: Windows
+- env: jobname=Windows
   os: linux
   compiler:
   addons:
@@ -55,7 +55,7 @@ matrix:
   test "$TRAVIS_REPO_SLUG" != "git/git" ||
   ci/run-windows-build.sh $TRAVIS_BRANCH $(git rev-parse HEAD)
   after_failure:
-- env: Linux32
+- env: jobname=Linux32
   os: linux
   compiler:
   services:
@@ -63,7 +63,7 @@ matrix:
   before_install:
   before_script:
   script: ci/run-linux32-docker.sh
-- env: Static Analysis
+- env: jobname=StaticAnalysis
   os: linux
   compiler:
   addons:
@@ -74,7 +74,7 @@ matrix:
   before_script:
   script: ci/run-static-analysis.sh
   after_failure:
-- env: Documentation
+- env: jobname=Documentation
   os: linux
   compiler:
   addons:
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh
index 5bd06fe90..468788566 100755
--- a/ci/install-dependencies.sh
+++ b/ci/install-dependencies.sh
@@ -8,8 +8,8 @@
 P4WHENCE=http://filehost.perforce.com/perforce/r$LINUX_P4_VERSION
 
LFSWHENCE=https://github.com/github/git-lfs/releases/download/v$LINUX_GIT_LFS_VERSION
 
-case "${TRAVIS_OS_NAME:-linux}" in
-linux)
+case "$jobname" in
+linux-clang|linux-gcc)
export GIT_TEST_HTTPD=YesPlease
 
mkdir --parents "$P4_PATH"
@@ -26,7 +26,7 @@ linux)
cp git-lfs-$LINUX_GIT_LFS_VERSION/git-lfs .
popd
;;
-osx)
+osx-clang|osx-gcc)
brew update --quiet
# Uncomment this if you want to run perf tests:
# brew install gnu-time
diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
index 2d0d1d613..4b3c5fdd0 100755
--- a/ci/lib-travisci.sh
+++ b/ci/lib-travisci.sh
@@ -29,8 +29,13 @@ set -ex
 
 skip_branch_tip_with_tag
 
-case "${TRAVIS_OS_NAME:-linux}" in
-linux)
+if test -z "$jobname"
+then
+   jobname="$TRAVIS_OS_NAME-$CC"
+fi
+
+case "$jobname" in
+linux-clang|linux-gcc)
P4_PATH="$(pwd)/custom/p4"
GIT_LFS_PATH="$(pwd)/custom/git-lfs"
export PATH="$GIT_LFS_PATH:$P4_PATH:$PATH"
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 1/8] travis-ci: use 'set -x' in select 'ci/*' scripts for extra tracing

[SZEDER Gábor]

While the build logic was embedded in our '.travis.yml', Travis CI
used to produce a nice trace log including all commands executed in
those embedded scriptlets.  Since 657343a60 (travis-ci: move Travis CI
code into dedicated scripts, 2017-09-10), however, we only see the
name of the dedicated scripts, but not what those scripts are actually
doing, resulting in a less useful trace log about e.g. installing
dependencies.  A patch later in this series will move setting
environment variables from '.travis.yml' to 'ci/lib-travisci.sh', so
not even those will be included in the trace log.  Unrelated to
657343a60, 'ci/test-documentation.sh' runs a bunch of 'test -s '
checks which would fail quietly if something were wrong, leaving no
clue about which one of those checks triggered the failure.

Use 'set -x' in 'ci/lib-travisci.sh' to get more detailed trace log
about the commands executed in the 'ci/*' scripts.  Use it in
'ci/run-linux32-build.sh' as well, which is run in a Docker container
and therefore doesn't source 'ci/lib-travisci.sh'.  The secret token
used for the Windows builds is specified as an encrypted environment
variable in git/git repository settings on Travis CI and it's redacted
in the trace logs even with 'set -x'.  However, disable this tracing
in 'ci/print-test-failures.sh', as it produces far too much noise in
the output of that script.

Signed-off-by: SZEDER Gábor 
---
 ci/lib-travisci.sh| 6 --
 ci/print-test-failures.sh | 3 +++
 ci/run-linux32-build.sh   | 2 ++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
index ac05f1f46..2d0d1d613 100755
--- a/ci/lib-travisci.sh
+++ b/ci/lib-travisci.sh
@@ -22,8 +22,10 @@ skip_branch_tip_with_tag () {
 }
 
 # Set 'exit on error' for all CI scripts to let the caller know that
-# something went wrong
-set -e
+# something went wrong.
+# Set tracing executed commands, primarily setting environment variables
+# and installing dependencies.
+set -ex
 
 skip_branch_tip_with_tag
 
diff --git a/ci/print-test-failures.sh b/ci/print-test-failures.sh
index 8c8973cbf..f757e616c 100755
--- a/ci/print-test-failures.sh
+++ b/ci/print-test-failures.sh
@@ -5,6 +5,9 @@
 
 . ${0%/*}/lib-travisci.sh
 
+# Tracing executed commands would produce too much noise in this script.
+set +x
+
 for TEST_EXIT in t/test-results/*.exit
 do
if [ "$(cat "$TEST_EXIT")" != "0" ]
diff --git a/ci/run-linux32-build.sh b/ci/run-linux32-build.sh
index e30fb2cdd..a8518eddf 100755
--- a/ci/run-linux32-build.sh
+++ b/ci/run-linux32-build.sh
@@ -6,6 +6,8 @@
 #   run-linux32-build.sh [host-user-id]
 #
 
+set -x
+
 # Update packages to the latest available versions
 linux32 --32bit i386 sh -c '
 apt update >/dev/null &&
-- 
2.15.1.429.ga000dd9c7

[PATCH v2 0/8] Travis CI cleanups

[SZEDER Gábor]

This is a reroll of 'sg/travis-fixes'.

Changes since the previous round:

 - Patch 1 got updated following the discussion:

   - I went with enabling tracing executed commands everywhere,
 including the Windows build job, except where we know it causes way
 too much clutter, which is currently only
 'ci/print-test-failures.sh'.

   - Also enable this tracing in 'ci/run-linux32-build.sh', which
 doesn't source 'ci/lib-travisci.sh' as it's run inside a Docker
 container.

   - The commit message got updated accordingly, including a note about
 the Windows build job's secret token.
 I would like to get an Acked-by: from Dscho on this patch before it
 gets merged.

 - Patches 5-8 are new.  They are various fixes/cleanups unrelated to
   the Travis CI scriptification, but I don't think it's worth to have
   them in separate patch series.

SZEDER Gábor (8):
  travis-ci: use 'set -x' in select 'ci/*' scripts for extra tracing
  travis-ci: introduce a $jobname variable for 'ci/*' scripts
  travis-ci: move setting environment variables to 'ci/lib-travisci.sh'
  travis-ci: set GIT_TEST_HTTPD in 'ci/lib-travisci.sh'
  travis-ci: don't install default addon packages for the 32 bit Linux
build
  travis-ci: don't install 'language-pack-is' package
  travis-ci: save prove state for the 32 bit Linux build
  travis-ci: only print test failures if there are test results
available

 .travis.yml| 28 ++--
 ci/install-dependencies.sh |  8 +++-
 ci/lib-travisci.sh | 38 ++
 ci/print-test-failures.sh  |  9 +
 ci/run-linux32-build.sh|  3 +++
 ci/run-linux32-docker.sh   |  1 +
 6 files changed, 56 insertions(+), 31 deletions(-)

-- 
2.15.1.429.ga000dd9c7

[PATCH] config: document default value of http.sslVerify

[Simon Ruderich]

Remove any doubt that certificates might not be verified by
default.

Signed-off-by: Simon Ruderich 
---
 Documentation/config.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3a1304874..0d49bcd70 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1968,8 +1968,8 @@ empty string.
 
 http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
-   over HTTPS. Can be overridden by the `GIT_SSL_NO_VERIFY` environment
-   variable.
+   over HTTPS. Defaults to true. Can be overridden by the
+   `GIT_SSL_NO_VERIFY` environment variable.
 
 http.sslCert::
File containing the SSL certificate when fetching or pushing
-- 
2.15.1

-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[PATCH] p7519: improve check for prerequisite WATCHMAN

[René Scharfe]

The return code of command -v with a non-existing command is 1 in bash
and 127 in dash.  Use that return code directly to allow the script to
work with dash and without watchman (e.g. on Debian).

While at it stop redirecting the output.  stderr is redirected to
/dev/null by test_lazy_prereq already, and stdout can actually be 
useful -- the path of the found watchman executable is sent there, but
it's shown only if the script was run with --verbose.

Signed-off-by: Rene Scharfe 
---
 t/perf/p7519-fsmonitor.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/t/perf/p7519-fsmonitor.sh b/t/perf/p7519-fsmonitor.sh
index 16d1bf72e5..65e145c02d 100755
--- a/t/perf/p7519-fsmonitor.sh
+++ b/t/perf/p7519-fsmonitor.sh
@@ -40,8 +40,7 @@ test_lazy_prereq UNTRACKED_CACHE '
 '
 
 test_lazy_prereq WATCHMAN '
-   { command -v watchman >/dev/null 2>&1; ret=$?; } &&
-   test $ret -ne 1
+   command -v watchman
 '
 
 if test_have_prereq WATCHMAN
-- 
2.15.1

[PATCH] revision: introduce prepare_revision_walk_extended()

[René Scharfe]

prepare_revision_walk() allows callers to take ownership of the array of
pending objects by setting the rev_info flag "leak_pending" and copying
the object_array "pending".  They use it to clear commit marks after
setup is done.  This interface is brittle enough that it requires
extensive comments.

Provide an easier way by adding a function that can hand over the array
to a caller-supplied output parameter and converting all users of the
flag "leak_pending" to call prepare_revision_walk_extended() instead.

Signed-off-by: Rene Scharfe 
---
 Documentation/technical/api-revision-walking.txt |  6 ++
 bisect.c | 17 +
 builtin/checkout.c   |  9 +
 bundle.c |  9 +
 revision.c   | 10 +-
 revision.h   | 14 ++
 6 files changed, 24 insertions(+), 41 deletions(-)

diff --git a/Documentation/technical/api-revision-walking.txt 
b/Documentation/technical/api-revision-walking.txt
index 55b878ade8..9dc573d2ec 100644
--- a/Documentation/technical/api-revision-walking.txt
+++ b/Documentation/technical/api-revision-walking.txt
@@ -50,6 +50,12 @@ function.
returns any error (non-zero return code) and if it does not, you can
start using get_revision() to do the iteration.
 
+`prepare_revision_walk_extended`::
+
+   Like prepare_revision_walk(), but allows callers to take ownership
+   of the array of pending objects by passing an object_array pointer
+   as the second parameter; passing NULL clears the array.
+
 `get_revision`::
 
Takes a pointer to a `rev_info` structure and iterates over it,
diff --git a/bisect.c b/bisect.c
index 0fca17c02b..a2af405d28 100644
--- a/bisect.c
+++ b/bisect.c
@@ -641,9 +641,10 @@ static void bisect_rev_setup(struct rev_info *revs, const 
char *prefix,
/* XXX leak rev_argv, as "revs" may still be pointing to it */
 }
 
-static void bisect_common(struct rev_info *revs)
+static void bisect_common(struct rev_info *revs,
+ struct object_array *old_pending_ptr)
 {
-   if (prepare_revision_walk(revs))
+   if (prepare_revision_walk_extended(revs, old_pending_ptr))
die("revision walk setup failed");
if (revs->tree_objects)
mark_edges_uninteresting(revs, NULL);
@@ -825,15 +826,7 @@ static int check_ancestors(const char *prefix)
bisect_rev_setup(, prefix, "^%s", "%s", 0);
 
/* Save pending objects, so they can be cleaned up later. */
-   pending_copy = revs.pending;
-   revs.leak_pending = 1;
-
-   /*
-* bisect_common calls prepare_revision_walk right away, which
-* (together with .leak_pending = 1) makes us the sole owner of
-* the list of pending objects.
-*/
-   bisect_common();
+   bisect_common(, _copy);
res = (revs.commits != NULL);
 
/* Clean up objects used, as they will be reused. */
@@ -964,7 +957,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
bisect_rev_setup(, prefix, "%s", "^%s", 1);
revs.limited = 1;
 
-   bisect_common();
+   bisect_common(, NULL);
 
find_bisection(, , , !!skipped_revs.nr);
revs.commits = managed_skipped(revs.commits, );
diff --git a/builtin/checkout.c b/builtin/checkout.c
index e1e157d205..1f04f5d5e5 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -796,14 +796,7 @@ static void orphaned_commit_warning(struct commit *old, 
struct commit *new)
add_pending_oid(, "HEAD", >object.oid, UNINTERESTING);
 
/* Save pending objects, so they can be cleaned up later. */
-   refs = revs.pending;
-   revs.leak_pending = 1;
-
-   /*
-* prepare_revision_walk (together with .leak_pending = 1) makes us
-* the sole owner of the list of pending objects.
-*/
-   if (prepare_revision_walk())
+   if (prepare_revision_walk_extended(, ))
die(_("internal error in revision walk"));
if (!(old->object.flags & UNINTERESTING))
suggest_reattach(old, );
diff --git a/bundle.c b/bundle.c
index 93290962c9..6af6e38c40 100644
--- a/bundle.c
+++ b/bundle.c
@@ -158,14 +158,7 @@ int verify_bundle(struct bundle_header *header, int 
verbose)
setup_revisions(2, argv, , NULL);
 
/* Save pending objects, so they can be cleaned up later. */
-   refs = revs.pending;
-   revs.leak_pending = 1;
-
-   /*
-* prepare_revision_walk (together with .leak_pending = 1) makes us
-* the sole owner of the list of pending objects.
-*/
-   if (prepare_revision_walk())
+   if (prepare_revision_walk_extended(, ))
die(_("revision walk setup failed"));
 
i = req_nr;
diff --git a/revision.c b/revision.c
index f6a3da5cd9..3a231451a4 100644
--- 

PAYMENT NOTIFICATION

[Mrs.Susan Dansuki]

Attention: Beneficiary,

Re:CONTACT MONEY GRAM OFFICE FOR YOUR PAYMENT OF $5,000.00

Be inform that We have been authorized by the United Nations Compensation 
Commission (UNCC) to release your compensation payment totaling the sum of 
US$1,500,000.00 through Money Gram transfer.You will be receiving the sum of 
US$5,000.00 daily until the total sum of US $1,500,000.00 is completely 
transferred to you.

Besides,we have already credited your first payment of US$5,000.00 
today,therefore,you are advice to contact our director of foreign Remittance 
Department MR.MARCEL OWURAH and request him to give you the details of your 
first payment such as MoneyGram reference Numbers and senders name to enable 
you pick up your first payment of US$5,000.00 at any Money Gram office located 
around you.Kindly contact him through the information stated below for faster 
process.

Contact Person: MR.MARCEL OWURAH
Telephone Number: +229 94 06 77 68
E-MAIL: transfermoney...@gmail.com

REMEMBER TO FORWARD HIM YOUR FULL INFORMATION AS REQUIRED BELOW TO ENABLE HIM 
LOCATE YOUR PAYMENT FILE AND ATTEND TO YOU IMMEDIATELY.

1. Your Full Name:
2. Address:
3. Age:
4. Occupation:
5. Telephone
6. Country:

NOTE: that the amount to be paid to you is (USD1.500,000.00 ),we expect your 
urgent response to this email to enable us monitor the payment effectively.

Best Regards
Mrs.Susan Dansuki.

Re: Trying to use insteadOf trick to use different SSH keys for separate github accounts - not working

[Asfand Qazi]

Thanks it worked! I was reading all the tutorials wrong all this time...

Regards,
 Asfand


On 16 December 2017 at 09:48, Jeff King  wrote:
> On Sat, Dec 16, 2017 at 07:50:02AM +, Asfand Qazi wrote:
>
>> I found out about the 'insteadOf' setting, and thought it would work.
>> So I added this to my global git config:
>>
>> [url "g...@github.com:MyCompany/"]
>> insteadOf = g...@work.github.com:MyCompany/
>>
>> and left the SSH hostname setting where it was. Then I tried doing:
>>
>> git clone git:github.com/MyCompany/la-repo.git
>>
>> But it won't work. With GIT_TRACE=2, I get:
>
> If I'm reading it right, you have the config backwards. You want to
> convert g...@github.com from Go's invocation of Git into your special
> "work" alias. So:
>
>   [url "g...@work.github.com:MyCompany/"]
>   insteadOf = "g...@github.com:MyCompany/"
>
> -Peff

Re: Git Hooks

[Jeff King]

On Fri, Dec 15, 2017 at 12:48:07PM -0800, Satyakiran Duggina wrote:

> To give the code pullers a chance to review, can we not have a
> `trusted-hooks: default` and `trusted-SHA: ` field in .git/.
> I'm assuming githooks/ are source tracked here.
> 
> When developer tries to execute `git commit`, git can ask developer to
> change `trusted-hooks` field to true or false. Let's say developer
> sets it to true, git can record the SHA. If any latest pull has the
> hooks changed, git can revert the `trusted-hook` to default.
> 
> This way there is not much hassle for developers to manually copy
> hooks all the time. And at the same time, they are not running scripts
> that they haven't reviewed.

We've talked about doing something like this (though more for config
than for hooks). But what the discussion always come down to is that
carrying a script like "import-hooks.sh" in the repository ends up being
the exact same amount of work for the developer as any git-blessed "OK,
trust these hooks" command.

And it's a lot more flexible. The writer of that script can touch hooks,
config, etc. They can base decisions about what values to use based on
data that Git otherwise wouldn't care about (e.g., uname). And they only
have to handle cases that the project cares about, whereas anything Git
does has to work everywhere.

-Peff

Re: Trying to use insteadOf trick to use different SSH keys for separate github accounts - not working

[Jeff King]

On Sat, Dec 16, 2017 at 07:50:02AM +, Asfand Qazi wrote:

> I found out about the 'insteadOf' setting, and thought it would work.
> So I added this to my global git config:
> 
> [url "g...@github.com:MyCompany/"]
> insteadOf = g...@work.github.com:MyCompany/
> 
> and left the SSH hostname setting where it was. Then I tried doing:
> 
> git clone git:github.com/MyCompany/la-repo.git
> 
> But it won't work. With GIT_TRACE=2, I get:

If I'm reading it right, you have the config backwards. You want to
convert g...@github.com from Go's invocation of Git into your special
"work" alias. So:

  [url "g...@work.github.com:MyCompany/"]
  insteadOf = "g...@github.com:MyCompany/"

-Peff

Re: Re* [PATCH v2 2/2] t: add tests for pull --verify-signatures

[Hans Jerry Illikainen]

On Fri, Dec 15, 2017 at 11:48:29AM -0800, Junio C Hamano wrote:
> Here is what I would propose as a follow-up polishing.
> 
> -- >8 --
> Subject: [PATCH 3/2] t5573: clean up after unexpected success of 'pull', too
> 
> The previous step added test_when_finished to tests that run 'git
> pull' with expectation of success, so that the test after them can
> start from a known state even when their 'git pull' invocation
> unexpectedly fails.  However, tests that run 'git pull' expecting
> it not to succeed forgot to protect later tests the same way---if
> they unexpectedly succeed, the test after them would start from an
> unexpected state.
> 
> Reset and checkout the initial commit after all these tests, whether
> they expect their 'git pull' invocations to succeed or fail.
> 
> Signed-off-by: Junio C Hamano 
> ---
>  t/t5573-pull-verify-signatures.sh | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

Thanks!  t7612-merge-verify-signatures.sh also lacks cleanup for
test_must_fail brokenness.  Would you prefer test_when_finished to be
included in the two patches as a v3?

-- 
hji

[PATCH v5 2/3] rebase: distinguish user input by quoting it

[Kaartic Sivaraam]

Signed-off-by: Kaartic Sivaraam 
Signed-off-by: Junio C Hamano 
Signed-off-by: Kaartic Sivaraam 
---
 git-rebase.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index a299bcc52..0f379ba2b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -477,7 +477,7 @@ then
;;
esac
upstream=$(peel_committish "${upstream_name}") ||
-   die "$(eval_gettext "invalid upstream \$upstream_name")"
+   die "$(eval_gettext "invalid upstream '\$upstream_name'")"
upstream_arg="$upstream_name"
 else
if test -z "$onto"
@@ -539,7 +539,7 @@ case "$#" in
head_name="detached HEAD"
 
else
-   die "$(eval_gettext "fatal: no such branch/commit: 
\$branch_name")"
+   die "$(eval_gettext "fatal: no such branch/commit 
'\$branch_name'")"
fi
;;
 0)
-- 
2.15.0.531.g2ccb3012c

[PATCH v5 3/3] rebase: rebasing can also be done when HEAD is detached

[Kaartic Sivaraam]

Attempting to rebase when the HEAD is detached and is already
up to date with upstream (so there's nothing to do), the
following message is shown

Current branch HEAD is up to date.

which is clearly wrong as HEAD is not a branch.

Handle the special case of HEAD correctly to give a more precise
error message.

Signed-off-by: Kaartic Sivaraam 
Signed-off-by: Junio C Hamano 
Signed-off-by: Kaartic Sivaraam 
---
 git-rebase.sh | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 0f379ba2b..fd72a35c6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -601,11 +601,23 @@ then
test -z "$switch_to" ||
GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \
git checkout -q "$switch_to" --
-   say "$(eval_gettext "Current branch \$branch_name is up to 
date.")"
+   if test "$branch_name" = "HEAD" &&
+! git symbolic-ref -q HEAD
+   then
+   say "$(eval_gettext "HEAD is up to date.")"
+   else
+   say "$(eval_gettext "Current branch \$branch_name is up 
to date.")"
+   fi
finish_rebase
exit 0
else
-   say "$(eval_gettext "Current branch \$branch_name is up to 
date, rebase forced.")"
+   if test "$branch_name" = "HEAD" &&
+! git symbolic-ref -q HEAD
+   then
+   say "$(eval_gettext "HEAD is up to date, rebase 
forced.")"
+   else
+   say "$(eval_gettext "Current branch \$branch_name is up 
to date, rebase forced.")"
+   fi
fi
 fi
 
-- 
2.15.0.531.g2ccb3012c

[PATCH v5 1/3] rebase: consistently use branch_name variable

[Kaartic Sivaraam]

The variable "branch_name" holds the  parameter in "git
rebase  ", but one codepath did not use it after
assigning $1 to it (instead it kept using $1).  Make it use the
variable consistently.

Also, update an error message to say there is no such branch or
commit, as we are expecting either of them, and not limiting
ourselves to a branch name.

Signed-off-by: Kaartic Sivaraam 
Signed-off-by: Junio C Hamano 
Signed-off-by: Kaartic Sivaraam 
---
 git-rebase.sh | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 60b70f3de..a299bcc52 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -518,7 +518,7 @@ case "$onto_name" in
 esac
 
 # If the branch to rebase is given, that is the branch we will rebase
-# $branch_name -- branch being rebased, or HEAD (already detached)
+# $branch_name -- branch/commit being rebased, or HEAD (already detached)
 # $orig_head -- commit object name of tip of the branch before rebasing
 # $head_name -- refs/heads/ or "detached HEAD"
 switch_to=
@@ -528,15 +528,18 @@ case "$#" in
branch_name="$1"
switch_to="$1"
 
-   if git show-ref --verify --quiet -- "refs/heads/$1" &&
-  orig_head=$(git rev-parse -q --verify "refs/heads/$1")
+   # Is it a local branch?
+   if git show-ref --verify --quiet -- "refs/heads/$branch_name" &&
+  orig_head=$(git rev-parse -q --verify "refs/heads/$branch_name")
then
-   head_name="refs/heads/$1"
-   elif orig_head=$(git rev-parse -q --verify "$1")
+   head_name="refs/heads/$branch_name"
+   # If not is it a valid ref (branch or commit)?
+   elif orig_head=$(git rev-parse -q --verify "$branch_name")
then
head_name="detached HEAD"
+
else
-   die "$(eval_gettext "fatal: no such branch: \$branch_name")"
+   die "$(eval_gettext "fatal: no such branch/commit: 
\$branch_name")"
fi
;;
 0)
@@ -547,7 +550,7 @@ case "$#" in
branch_name=$(expr "z$branch_name" : 'zrefs/heads/\(.*\)')
else
head_name="detached HEAD"
-   branch_name=HEAD ;# detached
+   branch_name=HEAD
fi
orig_head=$(git rev-parse --verify HEAD) || exit
;;
-- 
2.15.0.531.g2ccb3012c

[PATCH v5 0/3] rebase: give precise error messages

[Kaartic Sivaraam]

The tip of the v4 of this patch can be found at [1]. It was a revamp
sent by Junio mostly touching [PATCH v2 1/3] of the series. I've updated
it a little to add in something of my taste ;-)

There's only one concern that still bothers me a little. With the current
code you would see the following,

$ git rebase origin/maint 3013dff86
Current branch 3013dff86 is up to date.

That doesn't look good, does it? How about we overcome the issue of
handling this case and the HEAD case done in 3/3 by simplifying the
message as shown in the following diff,

diff --git a/git-rebase.sh b/git-rebase.sh
index 0f379ba2b..4d5400034 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -601,11 +601,11 @@ then
test -z "$switch_to" ||
GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \
git checkout -q "$switch_to" --
-   say "$(eval_gettext "Current branch \$branch_name is up to 
date.")"
+   say "$(eval_gettext "\$branch_name is up to date.")"
finish_rebase
exit 0
else
-   say "$(eval_gettext "Current branch \$branch_name is up to 
date, rebase forced.")"
+   say "$(eval_gettext "\$branch_name is up to date, rebase 
forced.")"
fi
 fi

I guess this one is much better than 3/3 of this series as it handles
any kind of case by making no assumptions.

Thoughts ??


Note: In case you're wondering where's v3 of this series, there wasn't
a v3 series but there was a v3 PATCH of 3/3 [2].

References:

[1]: 

[2]: <20171201060935.19749-1-kaartic.sivar...@gmail.com>

Here's the interdiff between v4 and v5,

diff --git a/git-rebase.sh b/git-rebase.sh
index f3dd86443..fd72a35c6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -518,7 +518,7 @@ case "$onto_name" in
 esac
 
 # If the branch to rebase is given, that is the branch we will rebase
-# $branch_name -- branch being rebased, or HEAD (already detached)
+# $branch_name -- branch/commit being rebased, or HEAD (already detached)
 # $orig_head -- commit object name of tip of the branch before rebasing
 # $head_name -- refs/heads/ or "detached HEAD"
 switch_to=
@@ -602,7 +602,7 @@ then
GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \
git checkout -q "$switch_to" --
if test "$branch_name" = "HEAD" &&
-!(git symbolic-ref -q HEAD)
+! git symbolic-ref -q HEAD
then
say "$(eval_gettext "HEAD is up to date.")"
else
@@ -612,7 +612,7 @@ then
exit 0
else
if test "$branch_name" = "HEAD" &&
-!(git symbolic-ref -q HEAD)
+! git symbolic-ref -q HEAD
then
say "$(eval_gettext "HEAD is up to date, rebase 
forced.")"
else



Kaartic Sivaraam (3):
  rebase: consistently use branch_name variable
  rebase: distinguish user input by quoting it
  rebase: rebasing can also be done when HEAD is detached

 git-rebase.sh | 35 +--
 1 file changed, 25 insertions(+), 10 deletions(-)

-- 
2.15.0.531.g2ccb3012c

[PATCH v5 0/1] clarify about @{-N} syntax in check-ref-format documentation

[Kaartic Sivaraam]

This was previously [PATCH v4 2/2] of this thread. It has now been
detached from 1/2 as it got merged to 'master'.

This patch applies on top of 'master'.

As this is almost a v2 of the v4 2/2 I'm comparing the changes with
v3 2/2 of the series. Apart from the changes shown by the below interdiff
the commit message got changed,

--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -78,20 +78,22 @@ reference name expressions (see linkgit:gitrevisions[7]):
 . at-open-brace `@{` is used as a notation to access a reflog entry.
 
 With the `--branch` option, the command takes a name and checks if
-it can be used as a valid branch name e.g. when creating a new branch
-(except for one exception related to the previous checkout syntax
-noted below). The rule `git check-ref-format --branch $name` implements
+it can be used as a valid branch name (e.g. when creating a new
+branch). But be cautious when using the
+previous checkout syntax that may refer to a detached HEAD state.
+The rule `git check-ref-format --branch $name` implements
 may be stricter than what `git check-ref-format refs/heads/$name`
 says (e.g. a dash may appear at the beginning of a ref component,
 but it is explicitly forbidden at the beginning of a branch name).
 When run with `--branch` option in a repository, the input is first
 expanded for the ``previous checkout syntax''
 `@{-n}`.  For example, `@{-1}` is a way to refer the last thing that
-was checkout using "git checkout" operation. This option should be
+was checked out using "git checkout" operation. This option should be
 used by porcelains to accept this syntax anywhere a branch name is
 expected, so they can act as if you typed the branch name. As an
 exception note that, the ``previous checkout operation'' might result
-in a commit hash when the N-th last thing checked out was not a branch.
+in a commit object name when the N-th last thing checked out was not
+a branch.
 
 OPTIONS
 ---



Kaartic Sivaraam (1):
  Doc/check-ref-format: clarify information about @{-N} syntax

 Documentation/git-check-ref-format.txt | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

-- 
2.15.0.531.g2ccb3012c

[PATCH v5 1/1] Doc/check-ref-format: clarify information about @{-N} syntax

[Kaartic Sivaraam]

When the N-th previous thing checked out syntax (@{-N}) is used
with '--branch' option of check-ref-format the result may not be
the name of a branch that currently exists or ever existed. This
is because @{-N} is used to refer to the N-th last checked out
"thing", which might be a commit object name if the previous check
out was a detached HEAD state; or a branch name, otherwise. The
documentation thus does a wrong thing by promoting it as the
"previous branch syntax".

State that @{-N} is the syntax for specifying "N-th last thing
checked out" and also state that the result of using @{-N} might
also result in an commit object name.

Signed-off-by: Kaartic Sivaraam 
---
 Documentation/git-check-ref-format.txt | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index cf0a0b7df..d9de99258 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -79,16 +79,21 @@ reference name expressions (see linkgit:gitrevisions[7]):
 
 With the `--branch` option, the command takes a name and checks if
 it can be used as a valid branch name (e.g. when creating a new
-branch).  The rule `git check-ref-format --branch $name` implements
+branch). But be cautious when using the
+previous checkout syntax that may refer to a detached HEAD state.
+The rule `git check-ref-format --branch $name` implements
 may be stricter than what `git check-ref-format refs/heads/$name`
 says (e.g. a dash may appear at the beginning of a ref component,
 but it is explicitly forbidden at the beginning of a branch name).
 When run with `--branch` option in a repository, the input is first
-expanded for the ``previous branch syntax''
-`@{-n}`.  For example, `@{-1}` is a way to refer the last branch you
-were on.  This option should be used by porcelains to accept this
-syntax anywhere a branch name is expected, so they can act as if you
-typed the branch name.
+expanded for the ``previous checkout syntax''
+`@{-n}`.  For example, `@{-1}` is a way to refer the last thing that
+was checked out using "git checkout" operation. This option should be
+used by porcelains to accept this syntax anywhere a branch name is
+expected, so they can act as if you typed the branch name. As an
+exception note that, the ``previous checkout operation'' might result
+in a commit object name when the N-th last thing checked out was not
+a branch.
 
 OPTIONS
 ---
@@ -116,7 +121,7 @@ OPTIONS
 EXAMPLES
 
 
-* Print the name of the previous branch:
+* Print the name of the previous thing checked out:
 +
 
 $ git check-ref-format --branch @{-1}
-- 
2.15.0.531.g2ccb3012c