Re: What's cooking in git.git (Mar 2017, #11; Mon, 27)

> On 28 Mar 2017, at 00:35, Junio C Hamano wrote: > ... > > * ls/filter-process-delayed (2017-03-06) 1 commit > - convert: add "status=delayed" to filter process protocol > > What's the status of this one??? > cf. I was

Re: [GSoC] Git CI Improvements 5 microproject

> On 24 Mar 2017, at 14:58, Nikita Kunevich wrote: > > Hello, git team. My name is Nikita Kunevich. I’m student of Belarusian State > University of Informatics and Radioelectronics. I’d like to particapate in > Google Summer of Code 2017 under git organization. > I’m

Re: [PATCH v2] travis-ci: build and test Git on Windows

> On 24 Mar 2017, at 12:48, Daniel Stenberg <dan...@haxx.se> wrote: > > On Fri, 24 Mar 2017, Lars Schneider wrote: > >> Most Git developers work on Linux and they have no way to know if their >> changes would break the Git for Windows build. Let's fix that b

[PATCH v2] travis-ci: build and test Git on Windows

Concurrent-Builds Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Hi, I think I addressed all issues from the v1 review (see interdiff below) with one exception. The script still uses bash instead of sh. Something about this does not work in sh: --output >(sed "$(

Re: [PATCH v1] travis-ci: build and test Git on Windows

> On 23 Mar 2017, at 21:20, Jeff King <p...@peff.net> wrote: > > On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote: > >>> Ah, OK, that makes sense. So we would only have to worry about our _own_ >>> code accidentally disclosing

Re: [PATCH v1] travis-ci: build and test Git on Windows

> On 23 Mar 2017, at 20:38, Jeff King <p...@peff.net> wrote: > > On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote: > >>> I think we do build against PRs now. E.g.: >>> >>> https://travis-ci.org/git/git/builds/213896051 >>> &

Re: [PATCH v1] travis-ci: build and test Git on Windows

> On 23 Mar 2017, at 20:30, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> "[...] we do not provide these values to untrusted builds, >> triggered by pull requests from another repository." &

Re: [PATCH v1] travis-ci: build and test Git on Windows

> On 23 Mar 2017, at 20:17, Jeff King wrote: > > On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >>> For instance, if it's in the environment, can I push up a branch that >>> does "set | grep GFW_CI_TOKEN", open a PR,

Re: [PATCH v1] travis-ci: build and test Git on Windows

> On 22 Mar 2017, at 20:29, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> Therefore, we did the following: >> * Johannes Schindelin set up a Visual Studio Team Services build >> sponsored by Mic

Re: [PATCH v1] travis-ci: build and test Git on Windows

> On 22 Mar 2017, at 16:49, Johannes Schindelin <johannes.schinde...@gmx.de> > wrote: > > Hi Lars, > > On Wed, 22 Mar 2017, Lars Schneider wrote: ... >> + >> +gfwci () { >> +curl \ >> +-H "Authentication

Warn user about known Git Rebase bug?!

Hi, we rebased a branch using "--preserve-merges --interactive" and were surprised that the operation reported success although it silently omitted commits (Git 2.12 on Windows). A little search revealed that these are likely known bugs [1]. Would it make sense to print an appropriate warning

Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

> On 21 Mar 2017, at 18:43, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> Agreed. Would it be OK to store the "delayed" bit in the cache >> entry itself? The extended ce_flags are stored on

[PATCH v1] travis-ci: build and test Git on Windows

Concurrent-Builds Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Notes: Base Ref: master Web-Diff: https://github.com/larsxschneider/git/commit/322094c0a2 Checkout: git fetch https://github.com/larsxschneider/git travisci/win-v1 && git checkout

Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

> On 06 Mar 2017, at 22:08, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> On 04 Mar 2017, at 00:26, Junio C Hamano <gits...@pobox.com> wrote: >>> >>> >>> * ls/filte

Re: [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak

> On 17 Mar 2017, at 13:56, Junio C Hamano <gits...@pobox.com> wrote: > > Junio C Hamano <gits...@pobox.com> writes: > >> Lars Schneider <larsxschnei...@gmail.com> writes: >> >>> A quick bisect indicates that this patch might break &g

Re: [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak

> On 16 Mar 2017, at 06:50, Junio C Hamano wrote: > > "git name-rev" assigned a phony "far in the future" date to tips of > refs that are not pointing at tag objects, and favored names based > on a ref with the oldest date. This made it almost impossible for > an unannotated

Re: USE_SHA1DC is broken in pu

> On 17 Mar 2017, at 11:18, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 17 Mar 2017, at 03:22, Linus Torvalds <torva...@linux-foundation.org> >> wrote: >> >> I think there's a semantic merge error and it clashes with >> f18f816

Re: USE_SHA1DC is broken in pu

> On 17 Mar 2017, at 03:22, Linus Torvalds > wrote: > > I think there's a semantic merge error and it clashes with > f18f816cb158 ("hash.h: move SHA-1 implementation selection into a > header file"). > > Suggested possible merge resolution attached. > >

[PATCH v3] Travis: also test on 32-bit Linux

ndelin <johannes.schinde...@gmx.de> Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Hi, when I looked into the 32-bit/line-log issue [1], I realized that my proposed docker setup is not ideal for local debugging. Here is an approach that I think is better. I changed the follow

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 02 Mar 2017, at 16:17, Ramsay Jones <ram...@ramsayjones.plus.com> wrote: > > > > On 02/03/17 11:24, Johannes Schindelin wrote: >> Hi Lars, >> >> On Thu, 2 Mar 2017, Lars Schneider wrote: >> > [snip] >>> One thing that still b

Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

> On 04 Mar 2017, at 00:26, Junio C Hamano wrote: > > > * ls/filter-process-delayed (2017-01-08) 1 commit > . convert: add "status=delayed" to filter process protocol > > Ejected, as does not build when merged to 'pu'. I send v2 [1] where I tried to address the points in

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 04 Mar 2017, at 05:11, Junio C Hamano wrote: > > On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote: >> >> I only recently started looking at Travis logs, so I cannot tell if >> it is just a usual flake (e.g. some builds a few days ago seems to >>

[PATCH v2] Travis: also test on 32-bit Linux

ndelin <johannes.schinde...@gmx.de> Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Hi, changes based on reviews since v2: - removed "set -e" - pass docker image name to run-linux32-build script - use Dscho's docker run formatting other changes:

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 02 Mar 2017, at 12:24, Johannes Schindelin <johannes.schinde...@gmx.de> > wrote: > > Hi Lars, > > On Thu, 2 Mar 2017, Lars Schneider wrote: > >> The patch looks good to me in general but I want to propose the following >> changes: > >

[PATCH v1] Travis: also test on 32-bit Linux

ndelin <johannes.schinde...@gmx.de> Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Thanks for the patch Dscho! The patch looks good to me in general but I want to propose the following changes: (1) Move all the docker magic into a dedicated file "ci/run-linux-32-build.

Re: [PATCH v2] convert: add "status=delayed" to filter process protocol

> On 27 Feb 2017, at 10:58, Jeff King <p...@peff.net> wrote: > > On Sun, Feb 26, 2017 at 07:48:16PM +0100, Lars Schneider wrote: > >> +If the request cannot be fulfilled within a reasonable amount of time >> +then the filter can respond with a "delayed&

[PATCH v2] convert: add "status=delayed" to filter process protocol

kouts only in `clone` (in unpack-trees.c) and `checkout` operations. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Hi, in v1 Junio criticized the "convert.h" interface of this patch [1]. After talking to Peff I think I understand Junio's point and I would like to ge

Re: [PATCH] travis-ci: run scan-build every time

> On 26 Feb 2017, at 03:09, Samuel Lijin <sxli...@gmail.com> wrote: > > On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >>> On 24 Feb 2017, at 18:29, Samuel Lijin <sxli...@gmail.com> wrote: >>> >

Re: [PATCH] travis-ci: run scan-build every time

> On 25 Feb 2017, at 23:31, Jeff King <p...@peff.net> wrote: > > On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote: > >> >>> On 24 Feb 2017, at 18:29, Samuel Lijin <sxli...@gmail.com> wrote: >>> >>> Introduces the scan-b

Re: SHA1 collisions found

> On 25 Feb 2017, at 00:06, Jeff King wrote: > > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > >> I have just read on ArsTechnica[1] that while Git repository could be >> corrupted (though this would require attackers to spend great amount >> of resources

Re: [PATCH] travis-ci: run scan-build every time

> On 24 Feb 2017, at 18:29, Samuel Lijin wrote: > > Introduces the scan-build static code analysis tool from the Clang > project to all Travis CI builds. Installs clang (since scan-build > needs clang as a dependency) to make this possible (on macOS, also > updates PATH to

[RFC] Subtle differences in passing configs to git clone

Hi, I stumbled across the following today: (1) git -c foo.bar="foobar" clone --> uses the config temporarily (2) git clone -c foo.bar="foobar" --> uses the config and writes it to .git/config This was introduced in 84054f7 ("clone: accept config options on the command line") and it

Re: [PATCH] config: preserve case for one-shot config on the command line

> On 20 Feb 2017, at 10:58, Junio C Hamano wrote: > > Junio C Hamano writes: > >> I still haven't queued any of the variants I posted (and I do not >> think other people sent their own versions, either). I need to pick >> one and queue, with a test or

Re: [PATCH] config: preserve case for one-shot config on the command line

t, too! > configuration variable is set to while the cmd is > running. The code to do so however downcased in its entirety, > which is wrong for a three-level ... > > The part needs to stay as-is. > > Reported-by: Lars Schneider <larsxschnei...@gmail.com> > Diagnosed-b

Re: git-p4.py caching

> On 14 Feb 2017, at 19:16, Martin-Louis Bright wrote: [CC'ing Luke and George] > hi! > > I am using git-p4.py to migrate a lot of medium and large Perforce > depots into git. I almost exclusively go one way: from Perforce to > git. I also frequently re-clone/re-migrate

[PATCH v1] t7400: cleanup "submodule add clone shallow submodule" test

The test creates a "super" directory that is not removed after the test finished. This directory is not used in any subsequent tests and should therefore be removed. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- I just noticed that my bug report test does not run

[BUG] submodule config does not apply to upper case submodules?

It looks like as if submodule configs ("submodule.*") for submodules with upper case names are ignored. The test cases shows that skipping a submodule during a recursive clone seems not to work. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- I observed the bug o

Re: [PATCH] cocci: detect useless free(3) calls

> On 11 Feb 2017, at 14:58, René Scharfe wrote: > > Add a semantic patch for removing checks that cause free(3) to only be > called with a NULL pointer, as that must be a programming mistake. > > Signed-off-by: Rene Scharfe > --- > No cases are found in master or

[PATCH v2] git-p4: fix git-p4.pathEncoding for removed files

s were not removed in a git-p4 cloned Git repository because the path names did not match. Fix this by moving the re-encoding to a place that affects "added" and "removed" paths. Add a test to demonstrate the issue. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com&

Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`

> On 06 Feb 2017, at 20:10, Junio C Hamano wrote: > > Johannes Schindelin writes: > >> So I thought maybe the From: line (from the body, if available, otherwise >> from the header) in conjunction with the "Date:" header would work. > > FYI, I

Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)

> On 26 Jan 2017, at 10:14, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 25 Jan 2017, at 23:51, Junio C Hamano <gits...@pobox.com> wrote: >> >> Jeff King <p...@peff.net> writes: >> >>> I guess the way to dig wou

Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)

> On 25 Jan 2017, at 23:51, Junio C Hamano wrote: > > Jeff King writes: > >> I guess the way to dig would be to add a test that looks at the output >> of "type mv" or something, push it to a Travis-hooked branch, and then >> wait for the output > > Sounds

Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)

> On 24 Jan 2017, at 14:27, Jeff King <p...@peff.net> wrote: > > On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote: > >> "fsck: prepare dummy objects for --connectivity-check" seems to >> make t1450-fsck.sh fail on macOS with TravisCI:

Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)

> On 24 Jan 2017, at 01:18, Junio C Hamano wrote: > > * jk/fsck-connectivity-check-fix (2017-01-17) 6 commits > (merged to 'next' on 2017-01-23 at e8e9b76b84) > + fsck: check HAS_OBJ more consistently > + fsck: do not fallback "git fsck " to "git fsck" > + fsck: tighten

Re: [RFC] Case insensitive Git attributes

> On 23 Jan 2017, at 20:38, Junio C Hamano wrote: > > Junio C Hamano writes: > >> So you are worried about the case where somebody on a case >> insensitive but case preserving system would do >> >> $ edit file.txt >> $ edit .gitattributes >> $ git

Re: [RFC] Case insensitive Git attributes

> On 23 Jan 2017, at 19:35, Junio C Hamano wrote: > > Dakota Hawkins writes: > >> Apologies for the delayed bump. I think because we're talking about >> affecting the behavior of .gitattributes that it would be better to >> have a distinct

Re: [PATCH v1] travis-ci: fix Perforce install on macOS

> On 23 Jan 2017, at 19:22, Junio C Hamano wrote: > > larsxschnei...@gmail.com writes: > >> Could you fast track the patch to `maint` if it works without trouble on >> `next` (as it should!)? >> >> Notes: >>Base Commit: 787f75f056 (master) > > I do not think there is

[PATCH v2] travis-ci: fix Perforce install on macOS

/homebrew-cask/pull/29180 [4] https://caskroom.github.io/ Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- Hi, this small update removes one more unnecessary line and makes the formula name lower case (no functional reason - just looks better ;-). @Junio: Do you prefer suc

Re: [PATCH] git-p4: Fix git-p4.mapUser on Windows

> On 21 Jan 2017, at 13:02, George Vanburgh wrote: > > From: George Vanburgh > > When running git-p4 on Windows, with multiple git-p4.mapUser entries in > git config - no user mappings are applied to the generated repository. > > Reproduction

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> On 09 Jan 2017, at 21:44, Stefan Beller <sbel...@google.com> wrote: > > On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> Hi, >> >> Git always performs a clean/smudge filter on files in sequential order

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

> On 10 Jan 2017, at 23:11, Jakub Narębski <jna...@gmail.com> wrote: > > W dniu 09.01.2017 o 00:42, Junio C Hamano pisze: >> larsxschnei...@gmail.com writes: >>> From: Lars Schneider <larsxschnei...@gmail.com> >>> >>> Some `clean`

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

> On 10 Jan 2017, at 00:38, Taylor Blau wrote: > > I've been considering some alternative approaches in order to make the > communication between Git and any extension that implements this protocol more > intuitive. > > In particular, I'm considering alternatives to: > >>

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

> On 08 Jan 2017, at 21:45, Eric Wong wrote: > > larsxschnei...@gmail.com wrote: >> +++ b/t/t0021/rot13-filter.pl > >> +$DELAY{'test-delay1.r'} = 1; >> +$DELAY{'test-delay3.r'} = 3; >> >> open my $debug, ">>", "rot13-filter.log" or die "cannot open log file: $!"; >> >> @@

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

> On 08 Jan 2017, at 21:14, Torsten Bögershausen <tbo...@web.de> wrote: > > On Sun, Jan 08, 2017 at 08:17:36PM +0100, larsxschnei...@gmail.com wrote: >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Some `clean` / `smudge` filters might require a s

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

> On 09 Jan 2017, at 00:42, Junio C Hamano <gits...@pobox.com> wrote: > > larsxschnei...@gmail.com writes: > >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Some `clean` / `smudge` filters might require a significant amount of >> ti

Re: [PATCH 1/2] asciidoctor: fix user-manual to be built by `asciidoctor`

> On 04 Jan 2017, at 09:08, Jeff King wrote: > > On Mon, Jan 02, 2017 at 05:03:57PM +0100, Johannes Schindelin wrote: > >> From: =?UTF-8?q?=EB=A7=88=EB=88=84=EC=97=98?= >> >> The `user-manual.txt` is designed as a `book` but the `Makefile` wants >> to

Re: HowTo distribute a hook with the reposity.

> On 28 Dec 2016, at 19:53, Jacob Keller wrote: > > On Tue, Dec 27, 2016 at 10:08 PM, Jeff King wrote: >> >> https://github.com/Autodesk/enterprise-config-for-git >> >> (with the disclaimer that I've never used it myself, so I have no >>

Re: What's cooking in git.git (Dec 2016, #08; Tue, 27)

> On 28 Dec 2016, at 00:11, Junio C Hamano wrote: > > > * bw/realpath-wo-chdir (2016-12-22) 5 commits > (merged to 'next' on 2016-12-22 at fea8fa870f) > + real_path: canonicalize directory separators in root parts > + real_path: have callers use real_pathdup and

Re: [PATCH] git-p4: do not pass '-r 0' to p4 commands

> On 29 Dec 2016, at 10:05, Igor Kushnir wrote: > > git-p4 crashes when used with a very old p4 client version > that does not support the '-r ' option in its commands. > > Allow making git-p4 work with old p4 clients by setting git-p4.retries to 0. > > Alternatively

Re: What's cooking in git.git (Dec 2016, #07; Thu, 22)

> On 22 Dec 2016, at 23:18, Junio C Hamano wrote: > > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the

Re: [RFC/PATCH v3 00/16] Add initial experimental external ODB support

> On 13 Dec 2016, at 18:20, Christian Couder <christian.cou...@gmail.com> wrote: > > On Sat, Dec 3, 2016 at 7:47 PM, Lars Schneider <larsxschnei...@gmail.com> > wrote: >> >>> On 30 Nov 2016, at 22:04, Christian Couder <christian.cou...@gmail.com> &

Re: test failure

> On 17 Dec 2016, at 15:28, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 16 Dec 2016, at 21:32, Ramsay Jones <ram...@ramsayjones.plus.com> wrote: >> >> Hi Lars, >> >> For the last two days, I've noticed t0021.15 on the 'p

Re: test failure

> On 16 Dec 2016, at 21:32, Ramsay Jones wrote: > > Hi Lars, > > For the last two days, I've noticed t0021.15 on the 'pu' branch has been > failing intermittently (well it fails with: 'make test >ptest-out', but > when run by hand, it fails only say 1-in-6,

Re: Serious bug with Git-2.11.0-64-bit and Git-LFS

ci-Fi Effects/Effects/Debris/Meshes/debris_junk.FBX" git commit -m "Move files properly to GitLFS" git push Afterwards you should be able to use the latest version of Git and GitLFS without trouble. Cheers, Lars PS: Top posting is not that popular in the Git community ;-) > >

Re: Serious bug with Git-2.11.0-64-bit and Git-LFS

> On 08 Dec 2016, at 12:46, Nick Warr wrote: > > Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with > 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS. > > When cloning a repo (large, 3.3 gig in git, 10.3 in LFS) for the > first time

Re: [PATCH v1] git-p4: add config to retry p4 commands; retry 3 times by default

> On 04 Dec 2016, at 15:03, larsxschnei...@gmail.com wrote: > > From: Lars Schneider <lars.schnei...@autodesk.com> Hi Junio, if you decide to queue this patch and/or the "git-p4: fix empty file processing for large file system backend GitLFS", please use my signed-of

Re: [RFC/PATCH v3 00/16] Add initial experimental external ODB support

> On 30 Nov 2016, at 22:04, Christian Couder wrote: > > Goal > > > Git can store its objects only in the form of loose objects in > separate files or packed objects in a pack file. > > To be able to better handle some kind of objects, for example big > blobs,

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> On 15 Nov 2016, at 19:03, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> The filter itself would need to be aware of parallelism >>> if it lives for multiple objects, right? >> >> Cor

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> On 17 Nov 2016, at 00:46, Junio C Hamano wrote: > > Jakub Narębski writes: > >>> I intend to implement this feature only for the new long running filter >>> process protocol. OK with you? >> >> If I remember and understand it correctly, current version

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> On 16 Nov 2016, at 19:15, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> * You'd need to rein in the maximum parallelism somehow, as you do >>> not want to see hundreds of competing filter pro

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

On 15 Nov 2016, at 19:03, Junio C Hamano <gits...@pobox.com> wrote: > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> The filter itself would need to be aware of parallelism >>> if it lives for multiple objects, right? >> >> Correct.

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

> On 15 Nov 2016, at 02:03, Eric Wong <e...@80x24.org> wrote: > > Lars Schneider <larsxschnei...@gmail.com> wrote: >> Hi, >> >> Git always performs a clean/smudge filter on files in sequential order. >> Sometimes a filter operation can take

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

> On 15 Nov 2016, at 13:07, Heiko Voigt <hvo...@hvoigt.net> wrote: > > On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote: >> To all macOS users on the list: >> Does anyone execute the tests with GIT_TEST_HTTPD enabled successfully? > > Nope

RFC: Enable delayed responses to Git clean/smudge filter requests

Hi, Git always performs a clean/smudge filter on files in sequential order. Sometimes a filter operation can take a noticeable amount of time. This blocks the entire Git process. I would like to give a filter process the possibility to answer Git with "I got your request, I am processing it,

Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables

> On 13 Nov 2016, at 02:13, Junio C Hamano wrote: > > Johannes Schindelin writes: > >>> Thanks. Dscho, does this fix both of these issues to you? >> >> Apparently it does because the CI jobs for `master` and for `next` pass. > > OK, thanks for

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

> On 11 Nov 2016, at 21:27, Jeff King wrote: > > On Fri, Nov 11, 2016 at 09:02:52PM +0100, Dennis Kaarsemaker wrote: > Are you sure about that? If I do: echo url=https://example.com/repo.git | git credential fill I get prompted for a username and

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 22:22, Johannes Sixt wrote: > > Am 11.11.2016 um 22:07 schrieb Junio C Hamano: >> Junio C Hamano writes: >> >>> OK, then let's have >>> >>> filter_git () { >>> rm -f rot13-filter.log && >>> git "$@" >>>

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 18:31, Lars Schneider <larsxschnei...@gmail.com> wrote: > >> >> On 11 Nov 2016, at 18:05, Lars Schneider <larsxschnei...@gmail.com> wrote: >> >> >>> On 11 Nov 2016, at 17:13, Johannes Schindelin <johannes.schinde...@

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 18:05, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 11 Nov 2016, at 17:13, Johannes Schindelin <johannes.schinde...@gmx.de> >> wrote: >> >> Hi Junio, >> >> On Thu, 10 Nov 2016, Junio C Hamano

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 17:13, Johannes Schindelin > wrote: > > Hi Junio, > > On Thu, 10 Nov 2016, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >>> I'll report back an updated schedule when able. >> >> I pushed some updates out on

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On 11 Nov 2016, at 10:31, Jeff King <p...@peff.net> wrote: > On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote: > >>> Yeah, that is the solution I was going to suggest. The credentials are >>> totally orthogonal to the filters, and

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On 10 Nov 2016, at 17:08, Jeff King <p...@peff.net> wrote: > On Thu, Nov 10, 2016 at 01:10:17PM +0100, Matthieu Moy wrote: > >> Lars Schneider <larsxschnei...@gmail.com> writes: >> >>> I haven't looked at an implemenation approach at all. I wonder if t

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On 11 Nov 2016, at 09:47, Jeff King <p...@peff.net> wrote: > On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote: > >> There would be an alternative way to approach the problem: >> Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of we

Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI

On 10 Nov 2016, at 22:34, Junio C Hamano <gits...@pobox.com> wrote: > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> I've followed what was available at the public-inbox archive, but it >>> is unclear what the conclusion was. >>> >

Re: [git-for-windows] [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

On 10 Nov 2016, at 22:39, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Lars, > > On Wed, 9 Nov 2016, Lars Schneider wrote: > >> On 05 Nov 2016, at 10:50, Johannes Schindelin <johannes.schinde...@gmx.de> >> wrote: >> >>>

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On 10 Nov 2016, at 17:10, Jeff King <p...@peff.net> wrote: > On Thu, Nov 10, 2016 at 12:07:14PM +0100, Lars Schneider wrote: > >>> Using Apache in the tests has been the source of frequent portability >>> problems and configuration headaches. I do wonder if we'

[RFC] Add way to make Git credentials accessible from clean/smudge filter

Hi, we just implemented the first "real-world" user of the new clean/smudge "filter protocol" interface (see "convert: add filter..process option" edcc858 for details) and the results are fantastic. Filtering 12,000 files in my artificial test repo is more than 60x faster (depending on the

Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI

> On 10 Nov 2016, at 00:39, Junio C Hamano <gits...@pobox.com> wrote: > > larsxschnei...@gmail.com writes: > >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Apple removed the OpenSSL header files in macOS and therefore Git does >>

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

> On 07 Nov 2016, at 22:20, Jeff King <p...@peff.net> wrote: > > On Sun, Nov 06, 2016 at 10:42:36PM +0100, Lars Schneider wrote: > >>> From: Lars Schneider <larsxschnei...@gmail.com> >>> >>> TravisCI changed their default macOS image from 10

Re: [git-for-windows] [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

On 05 Nov 2016, at 10:50, Johannes Schindelin wrote: > Dear Git users, > > I finally got around to rebase the Windows-specific patches (which seem to > not make it upstream as fast as we get new ones) on top of upstream Git > v2.11.0-rc0, and to bundle installers,

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

> On 09 Nov 2016, at 09:18, Torsten Bögershausen <tbo...@web.de> wrote: > > On 07.11.16 18:26, Jeff King wrote: >> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: >> >>> Good point. I think I found an even easier way to achieve the same. &

Re: [PATCH (optional)] t0021: use arithmetic expansion to trim whitespace from wc -c output

> On 06 Nov 2016, at 20:31, Johannes Sixt <j...@kdbg.org> wrote: > > Am 06.11.2016 um 16:45 schrieb Lars Schneider: >> >>> On 03 Nov 2016, at 21:22, Johannes Sixt <j...@kdbg.org> wrote: >>> This is a pure optimization that reduces the numb

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

> On 17 Oct 2016, at 02:25, larsxschnei...@gmail.com wrote: > > From: Lars Schneider <larsxschnei...@gmail.com> > > TravisCI changed their default macOS image from 10.10 to 10.11 [1]. > Unfortunately the HTTPD tests do not run out of the box using the > pre-installe

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

> On 17 Oct 2016, at 11:50, Jeff King <p...@peff.net> wrote: > > On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Apple removed the OpenSSL header files in macOS 10.11

Re: [PATCH (optional)] t0021: use arithmetic expansion to trim whitespace from wc -c output

> On 03 Nov 2016, at 21:22, Johannes Sixt wrote: > > Instead of a pipeline with sed and a useless use of cat, return the > unmodified text of wc -c from function file_size, but substitute the > result with arithmetic expansion to get rid of the leading whitespace > that some

Re: [PATCH] t0021: expect more variations in the output of uniq -c

ere it is as a proper patch. > > Am 03.11.2016 um 01:41 schrieb Lars Schneider: >>> On 2 Nov 2016, at 18:03, Johannes Sixt <j...@kdbg.org> wrote: >>> +sort "$FILE" | uniq -c | >>> +sed -e "s/^ *[0-9][0-9]* *IN: /x IN: /" >

Re: [PATCH 4/4] t0021: fix filehandle usage on older perl

> On 02 Nov 2016, at 19:23, Jeff King wrote: > > The rot13-filter.pl script calls methods on implicitly > defined filehandles (STDOUT, and the result of an open() > call). Prior to perl 5.13, these methods are not > automatically loaded, and perl will complain with: > > Can't

Re: [PATCH 3/4] t0021: use $PERL_PATH for rot13-filter.pl

> On 02 Nov 2016, at 19:20, Jeff King wrote: > > The rot13-filter.pl script hardcodes "#!/usr/bin/perl", and > does not respect $PERL_PATH at all. That is a problem if the > system does not have perl at that path, or if it has a perl > that is too old to run a complicated script

Re: [PATCH 1/4] t0021: use write_script to create rot13 shell script

> On 06 Nov 2016, at 15:29, Jeff King <p...@peff.net> wrote: > > On Sun, Nov 06, 2016 at 03:25:33PM +0100, Lars Schneider wrote: > >> This looks good to me (and it works on my machine). >> However, I took a look at the "write_script" function and f

Re: [PATCH 2/4] t0021: put $TEST_ROOT in $PATH

> On 02 Nov 2016, at 19:18, Jeff King wrote: > > We create a rot13.sh script in the trash directory, but need > to call it by its full path when we have moved our cwd to > another directory. Let's just put $TEST_ROOT in our $PATH so > that the script is always found. > > This is

<    1   2   3   4   5   6   7   8   9   10   >