Re: Re* [PATCH v2 2/2] t: add tests for pull --verify-signatures
Hans Jerry Illikainenwrites: > 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]
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
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
On Sat, Dec 16, 2017 at 5:48 PM, SZEDER Gáborwrote: > 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
> On Sat, Dec 16, 2017 at 7:58 AM, SZEDER G=C3=A1borw= > 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?
On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote: > Jonathan Niederwrites: > > 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
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
From: Torsten Bögershausenwc -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 Signed-off-by: Torsten Bögershausen --- I added Dscho as reviewer, thanks. If there is anything more, please holler. t/check-non-portable-shell.pl | 1 + 1 file changed, 1 insertion(+) 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'; /\bexport\s+[A-Za-z0-9_]*=/ and err '"export FOO=bar" is not portable (please use FOO=bar && export FOO)'; # this resets our $. for each file close ARGV if eof; -- 2.15.1.271.g1a4e40aa5d
[PATCH] l10n: de.po: improve messages when a branch starts to track another ref
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
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
Thomas Gummererwrites: > 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
On Sat, Dec 16, 2017 at 7:58 AM, SZEDER Gáborwrote: > 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
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
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.
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
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
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
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
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
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'
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'
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
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
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
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
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
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()
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
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
Thanks it worked! I was reading all the tutorials wrong all this time... Regards, Asfand On 16 December 2017 at 09:48, Jeff Kingwrote: > 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
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
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
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
Signed-off-by: Kaartic SivaraamSigned-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
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 SivaraamSigned-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
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 SivaraamSigned-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
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
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
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