Re: [PATCH] config.mak.uname: Cygwin: Use renames for creation

change for them, and then the official Cygwin packager of Git sends a patch our way. Wait a few releases then resubmit assuming we've not had complaints from Cygwin user. Okay! https://cygwin.com/ml/cygwin/2015-08/msg00102.html seems to indicate that somebody called Adam Dinwoodie is wearing Git

[PATCH] config.mak.uname: Cygwin: Use renames for creation

/msg00102.html (amongst others) and is being applied as a manual patch to the Cygwin builds until the patch is taken here. Reported-by: Peter Rosin p...@lysator.liu.se Signed-off-by: Adam Dinwoodie a...@dinwoodie.org --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH] config.mak.uname: Cygwin: Use renames for creation

On 09/08/2015 10:01, Johannes Schindelin wrote: On 2015-08-09 04:01, Adam Dinwoodie wrote: I do not see any difference between the situation here and the situation for MinGW, which is fundamentally a Cygwin fork, but which already has this build option set for it in config.mak.uname

Re: [PATCH] config.mak.uname: Cygwin: Use renames for creation

On Sat, Aug 08, 2015 at 09:06:28PM +, brian m. carlson wrote: On Sat, Aug 08, 2015 at 04:47:46PM -0400, Mark Levedahl wrote: On 08/07/2015 04:30 PM, Adam Dinwoodie wrote: When generating build options for Cygwin, enable OBJECT_CREATION_USES_RENAMES. This is necessary to use Git

Bug: t5813 failing on Cygwin

In the process of pulling up the Cygwin Git release from v2.5.3, I've discovered t5813 is failing, and appears to have been failing since it was first introduced in a5adace. I've not yet done any significant digging into the problem myself; I'm reporting here now in case in the hope someone

Re: Bug: t5813 failing on Cygwin

On Sat, Nov 07, 2015 at 01:45:27PM -0500, Jeff King wrote: > On Sat, Nov 07, 2015 at 12:11:29PM +0000, Adam Dinwoodie wrote: > > > Specifically, I'm seeing t5813 subtests 9-13 and 15-19 failing. This happens > > with a clean build straight from the Git source tree (git

Re: Bug: t5813 failing on Cygwin

On Sat, Nov 07, 2015 at 10:02:45PM +0100, Dennis Kaarsemaker wrote: > On za, 2015-11-07 at 19:20 +0000, Adam Dinwoodie wrote: > > On Sat, Nov 07, 2015 at 01:45:27PM -0500, Jeff King wrote: > > > On Sat, Nov 07, 2015 at 12:11:29PM +0000, Adam Dinwoodie wrote: > > > >

[PATCH] git-gui: Remove ancient Cygwin compatibility code

process. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- I'm the current Cygwin maintainer for Git; this code has been patched out of the Cygwin Git builds since v1.7.9,* well before I took over. It's clearly stable and causing no problems, so having it in the upstream code rathe

SVN clone on Cygwin drops a / and reports "not a complete URL"

Hi all, Currently, attempting to clone a Subversion repository using an svn:// or https:// URI specified with -T fails on Cygwin: $ git svn init -T svn://svn.code.sf.net/p/squirrelmail/code/trunk Initialized empty Git repository in /home/add/tmp/.git/ E:

Re: [PATCH] t9117: test specifying full url to git svn init -T

On Wed, Mar 16, 2016 at 07:34:07PM +, Eric Wong wrote: > Adam Dinwoodie <a...@dinwoodie.org> wrote: > > According to the documentation, full URLs can be specified in the `-T` > > argument to `git svn init`. However, the canonicalization of such > > arguments squashe

[PATCH] commit: --amend -m '' silently fails to wipe message

this behaviour. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- I've had to guess at the correct file to add these tests to; t7500 covers the mainline --allow-empty-message cases, while t7501 doesn't (currently) cover --allow-empty-message but does cover --amend. I've made an educated

Re: [PATCH] commit: --amend -m '' silently fails to wipe message

On Thu, Apr 07, 2016 at 12:42:19AM -0400, Jeff King wrote: > On Wed, Apr 06, 2016 at 06:15:03PM +0100, Adam Dinwoodie wrote: > > `git commit --amend -m ''` seems to be an unambiguous request to blank a > > commit message, but it actually leaves the commit message as-is. That

[PATCH] t9117: test specifying full url to git svn init -T

e evidence of that. On systems where Subversion provides svn_path_canonicalize but not svn_dirent_canonicalize (Subversion 1.6 and earlier?), this test passes, as svn_path_canonicalize doesn't mangle the consecutive "/"s. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- I think the bug her

Silent failure to add Windows-style paths in Cygwin Git

[Resending as my initial attempt appears to have not made it to the list. Apologies if this results in a double-post.] If I attempt to `git add` an extant file specified using a Windows-style path on Cygwin Git, this doesn't add the file, and produces no error message: $ pwd # As seen by

[PATCH] git-gui: Remove ancient Cygwin compatibility code

>From 50c9cbb6ce31529316ba004194f63a24ae59b4b0 Mon Sep 17 00:00:00 2001 From: Adam Dinwoodie <a...@dinwoodie.org> Date: Fri, 13 May 2016 11:52:32 +0100 Subject: [PATCH] git-gui: Remove unused Cygwin compatibility code Cygwin-distributed builds of git-gui have patched out the Cygwin

Bug report: Duplicate CRLF rewrite warnings on commit

If you use .gitattributes to enable CRLF->LF rewriting, then commit a file that would have its line endings rewritten, the "CRLF will be replaced by LF" warning is printed several times over; I'd expect it to be printed only once. There's a test case in t0020 -- "safecrlf: print warning only

Re: Bug report: Duplicate CRLF rewrite warnings on commit

On Sat, May 14, 2016 at 07:40:11AM +0200, Torsten Bögershausen wrote: > On 13.05.16 18:43, Junio C Hamano wrote: > > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a > >> file

[PATCH] crlf: Add test showing double warning on commit

Add failing test case showing CRLF -> LF rewrite warnings being printed multiple times when running "git commit". Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- t/t0020-crlf.sh | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/t/t002

Binary grep t7008 known breakage vanished on Cygwin

t7008.12 is marked as an expected failure, but building Git on Cygwin including a `make configure && ./configure` step has the test unexpectedly passing. Building without the configure step has the test failing as expected. This appears to be behaviour specific to Cygwin; at least I get that

Silent failure to add Windows-style paths in Cygwin Git

If I attempt to `git add` an extant file specified using a Windows-style path on Cygwin Git, this doesn't add the file, and produces no error message: $ pwd # As seen by Cygwin /cygdrive/c/tmp $ cygpath -aw . # As seen by Windows C:\tmp $ git init Initialized empty Git

[PATCH resubmission] config.mak.uname: Cygwin: Use renames for creation

When generating build options for Cygwin, enable OBJECT_CREATION_USES_RENAMES. This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. Reported-by: Peter Rosin <p...@lysator.liu.se> Signed-off-by: Adam Din

Re: Binary grep t7008 known breakage vanished on Cygwin

On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote: > On 18/04/16 16:21, Adam Dinwoodie wrote: > > t7008.12 is marked as an expected failure, but building Git on Cygwin > > including a `make configure && ./configure` step has the test > > unexpected

Re: Continous Integration (was: RE: Git v2.13.1 SHA1 very broken)

On Tue, Jun 06, 2017 at 05:04:32PM +0200, Lars Schneider wrote: > > On 06 Jun 2017, at 16:47, Jason Pyeron wrote: > > > > Do we have Jenkins (or something else) setup for Git? > > > > We would be happy to donate (slave) VMs for cygwin builds og Git. > > > > -Jason Pyeron >

Re: git v2.13.0-rc0 test failures on cygwin

On 23 April 2017 at 15:44, Ramsay Jones wrote: > [Adam, if you are no longer the git package maintainer for cygwin, then > please ignore this email and sorry for the noise!] I am still the Cygwin Git package maintainer; I've been quiet of late because of personal health issues, but I'm now

Re: t3700 broken on pu on Cygwin

On Tue, Aug 08, 2017 at 06:25:24PM +0100, Adam Dinwoodie wrote: > I'm running a bisect overnight to try to isolate the commit on the left > merge parent that seems to be interacting badly with the commit on the > right, and will send in the results from that when I have them. For

Re: t3700 broken on pu on Cygwin

On Tue, Aug 08, 2017 at 05:32:21PM +0200, René Scharfe wrote: > Am 08.08.2017 um 17:18 schrieb Adam Dinwoodie: > > The t3700-add.sh test is currently failing on the pu branch on Cygwin. > > To my surprise, the problem appears to have been introduced by a merge, > > 867

t3700 broken on pu on Cygwin

The t3700-add.sh test is currently failing on the pu branch on Cygwin. To my surprise, the problem appears to have been introduced by a merge, 867fa1d6a. Both parents of that merge have the test succeeding, but it's failing on that merge commit. Failing test output below: $ ./t3700-add.sh

Re: [PATCH] docs: suggest "Helped-by" rather than "Thanks-to"

(Resending to everyone after only sending to Junio by mistake.) On Wed, Jun 07, 2017 at 08:44:08AM +0900, Junio C Hamano wrote: > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote: > >> So I was wond

[PATCH] docs: fix literal quoted spaces

text. Instead, use + to avoid asciidoc's literal passthrough, and encode the space as {sp}. In particular, this means asciidoc will correctly detect the end of the monospace formatting, rather than having it continue past the backtick. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.

[PATCH] docs: suggest "Helped-by" rather than "Thanks-to"

;Thanks-to" is not common usage, and should instead be "Helped-by". Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/SubmittingPatches | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/Submi

Re: [PATCH] docs: fix literal quoted spaces

On Thu, Jun 01, 2017 at 11:06:18AM +0900, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Wed, May 31, 2017 at 04:06:24PM +0100, Adam Dinwoodie wrote: > > > >> Instead, use + to avoid asciidoc's literal passthrough, and encode the > >>

[PATCH v2] docs: fix formatting and grammar

aren't necessary and not having them keeps the markup simpler. Also include a minor grammar fix suggested by Jeff while we're changing these lines. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> Helped-by: Jeff King <p...@peff.net> --- Documentation/git-pull.txt | 4 ++-- 1 fil

Re: Git v2.13.1 SHA1 very broken

On Tue, Jun 06, 2017 at 10:20:45AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > That looks scary, can you please comment out this: > > > > #define SHA1DC_ALLOW_UNALIGNED_ACCESS > > > > In sha1dc/sha1.c and see if that helps, alternatively comment out

Re: CYGWIN git cannot install python packages with pip

On Wed, May 03, 2017 at 04:32:15PM +0200, Johannes Schindelin wrote: > On Wed, 3 May 2017, ankostis wrote: > > > On 3 May 2017 11:47, Johannes Schindelin wrote: > > > On Tue, 2 May 2017, ankostis wrote: > > > > > >> On Windows, with Cygwin-git 02.12.2-1 the python command: > > >> [...] > > > > >

Re: git v2.13.0-rc0 test failures on cygwin

On Fri, Apr 28, 2017 at 03:20:21PM -0400, Devin Lehmacher wrote: > > > Test Summary Report > > > --- > > > t0301-credential-cache.sh(Wstat: 256 Tests: 29 > > > Failed: 6) > > > Failed tests: 12, 24-28 > > > Non-zero exit status: 1 > > > > Confirmed I'm

Re: Git v2.13.1 SHA1 very broken

On Tue, Jun 06, 2017 at 08:55:04PM +0900, Junio C Hamano wrote: > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > Digging briefly into the endianness detection, it appears Cygwin has > > both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by > > as

Re: [PATCH] docs: suggest "Helped-by" rather than "Thanks-to"

On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote: > So I was wondering if there is a command that shows all trailers? > Similar to a "shortlog -sne" I would want to have a list of all trailers. > This is because there might be an even more popular trailer than > "Helped-by", but we

Git v2.13.1 SHA1 very broken

I'm trying to compile Git v2.13.1 to release for Cygwin, but it appears a010391 ("sha1dc: update from upstream", 2017-05-20) is breaking a very significant number of test cases in both 32-bit and 64-bit Cygwin builds. The first failure is t.46 "validate object ID of a known tree"; output with

Re: v2.15.0-rc1 test failure

On Thu, Oct 12, 2017 at 01:27:57AM +0100, Ramsay Jones wrote: > On 11/10/17 23:34, Adam Dinwoodie wrote: > [snip] > > Hi Ramsay, > > > > I assume, given you're emailing me, that this is a Cygwin failure? > > Yes, sorry, I should have made that clear. > >

Re: Unexpected pass for t6120-describe.sh on cygwin

On Sat, Sep 09, 2017 at 02:13:32PM +0100, Ramsay Jones wrote: > I ran the test-suite on the 'pu' branch last night (simply because > that was what I had built at the time!), which resulted in a PASS, > but t6120 was showing a 'TODO passed' for #52. Confirmed, I also see this unexpected pass. >

Re: [PATCH 1/1] fast-import: checkpoint: dump branches/tags/marks even if object_count==0

On Wed, Sep 27, 2017 at 10:07:41PM -0700, Eric Rannaud wrote: > The checkpoint command cycles packfiles if object_count != 0, a sensible > test or there would be no pack files to write. Since 820b931012, the > command also dumps branches, tags and marks, but still conditionally. > However, it is

[PATCH] doc: correct command formatting

Leaving spaces around the `-delimeters for commands means asciidoc fails to parse them as the start of a literal string. Remove an extraneous space that is causing a literal to not be formatted as such. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/git.txt | 2 +-

Re: cat-file timing window on Cygwin

On Sat, Aug 26, 2017 at 01:57:18AM +0100, Ramsay Jones wrote: > On 25/08/17 16:08, Jeff King wrote: > > On Fri, Aug 25, 2017 at 12:25:29PM +0100, Adam Dinwoodie wrote: > > > >> As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters > >> in b

Re: cat-file timing window on Cygwin

On Sat, Aug 26, 2017 at 11:53:37AM -0700, Jeff King wrote: > On Sat, Aug 26, 2017 at 01:57:18AM +0100, Ramsay Jones wrote: > > > > diff --git a/run-command.c b/run-command.c > > > index 98621faca8..064ebd1995 100644 > > > --- a/run-command.c > > > +++ b/run-command.c > > > @@ -641,7 +641,6 @@ int

Re: cat-file timing window on Cygwin

On Sun, Aug 27, 2017 at 03:06:31AM +0100, Ramsay Jones wrote: > On 26/08/17 22:11, Adam Dinwoodie wrote: > > On Sat, Aug 26, 2017 at 11:53:37AM -0700, Jeff King wrote: > >> Interesting. I find it a little hard to believe there's so obvious a bug > >> as "fflus

cat-file timing window on Cygwin

As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters in batch mode"), t8010-cat-file-filters.sh has been failing on Cygwin. Digging into this, the test looks to expose a timing window: it appears that if `git cat-file --textconv --batch` receives input on stdin too quickly, it

Re: v2.15.0-rc1 test failure

On Wed, Oct 11, 2017 at 11:15:57PM +0100, Ramsay Jones wrote: > Hi Adam, > > I had a test failure on the v2.15.0-rc1 build tonight. > The test in question being t0021-conversion.sh #15 > ('required process filter should filter data'). I didn't > have any test failures on v2.15.0-rc0, and I don't

Re: [PATCH] notes: add `rm` and `delete` commands

On Friday 10 November 2017 at 12:14 pm +0900, Junio C Hamano wrote: > Eric Sunshine writes: > > > or against the change: > > > > - synonym bloat; balloons documentation > > - steals command verbs from potential future features > > - ... > > I tend to agree

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: > > > merge-recursive.c | 1243 +++- > merge-recursive.h | 17 + > t/t3501-revert-cherry-pick.sh |5 +- > t/t6043-merge-rename-directories.sh | 3821 >

Bisect marking new commits incorrectly

In trying to do a bisect on the Git repository, I seem to have come across surprising behavior where the order in which `git bisect` appears to forget that previous commits were marked as new. You can see this behaviour in the following commands, run on the Git repository, where the order of the

Re: Bisect marking new commits incorrectly

On Wednesday 22 November 2017 at 05:21 pm +0100, Christian Couder wrote: > On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie <a...@dinwoodie.org> wrote: > > In trying to do a bisect on the Git repository, I seem to have come > > across surprising behavior where the order

[PATCH v4] doc/SubmittingPatches: correct subject guidance

as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match and to reference the `format-patch` helper arguments, and also make some minor text clarifications in the area. Signed-

[RFC PATCH v2 2/2] bisect: add "edit" command

his commit merely reduces those separate steps to a single step. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- builtin/bisect--helper.c | 3 ++- git-bisect.sh| 18 ++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/builtin/bisect--helper.c

[RFC PATCH v2 0/2] bisect: add a single command for editing logs

find a consensus on what best practice is for handling errors between the existing shell code in this script and git-rebase--interactive.sh. - There aren't yet any tests or documentation changes; I wanted to get commentary on the initial code changes before I spent time on those parts.

[RFC PATCH v2 1/2] bisect: split out replay file parsing

In order to allow a git bisect log file to be replayed without using all the surrounding code to do things like clean the repository state, split out the file-parsing part of bisect_replay into a separate function. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- git-bisect.

Re: t3512 & t3513 'unexpected passes'

On Monday 20 November 2017 at 08:16 pm +, Ramsay Jones wrote: > For several days, I have been staring at some 'unexpected passes' in > the t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test > files (tests #11-13 in both cases). > > I finally found time tonight to 'git bisect'

Re: [PATCH] t5580: add Cygwin support

On Wed, Nov 01, 2017 at 10:44:22AM +0900, Junio C Hamano wrote: > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > t5580 tests that specifying Windows UNC paths works with Git. Cygwin > > supports UNC paths, albeit only using forward slashes, not backslashes, > &g

Re: [PATCH v2] doc/SubmittingPatches: correct subject guidance

On Wednesday 08 November 2017 at 09:10 am -0500, Eric Sunshine wrote: > On Wed, Nov 8, 2017 at 8:47 AM, Adam Dinwoodie <a...@dinwoodie.org> wrote: > > +e-mail discussions. Use of markers in addition to PATCH within > > +the brackets to describe the nature of the patch is

[PATCH v3] doc/SubmittingPatches: correct subject guidance

as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match, and to reference the `format-patch` helper arguments. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.o

[PATCH] notes: add `rm` and `delete` commands

Add `git notes rm` and `git notes delete` as alternative ways of saying `git notes remove`. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/git-notes.txt | 4 +++- builtin/notes.c | 8 +--- t/t3301-notes.sh| 6 +++--- 3 files chang

[PATCH] doc/SubmittingPatches: correct subject guidance

r the closing bracket. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/SubmittingPatches | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 558d465b6..e91ce8269 100644 --- a/D

[PATCH v2] doc/SubmittingPatches: correct subject guidance

as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- I'm re-rolling this patch with some more substantive changes

[PATCH] rebase -i: fix comment typo

Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- git-rebase--interactive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 2563dc52d..437815669 100644 --- a/git-rebase--interactive.sh +++ b/git-

[RFC PATCH] rebisect: add script for easier bisect log editing

Add a short script, vaguely inspired by `git rebase --interactive`, to ease the process described in the `git bisect` documentation of saving off a bisect log, editing it, then replaying it. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- When I'm bisecting, I find I need t

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wednesday 08 November 2017 at 05:12 pm +0100, Christian Couder wrote: > On Wed, Nov 8, 2017 at 2:59 PM, Adam Dinwoodie <a...@dinwoodie.org> wrote: > > +git bisect reset HEAD > > I guess that using "reset HEAD" could be cheaper than just "reset&qu

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wednesday 08 November 2017 at 05:15 pm +0100, Christian Couder wrote: > >> +git bisect replay "$GIT_BISECT_LOG_TMP" > >> +rm -f "$GIT_BISECT_LOG_TMP" > > While at it, is there a reason for the -f option above? I was following the lead of git-bisect.sh, which has used `rm -f` for such things

Re: [PATCH 02/14] clone, fetch-pack, index-pack, transport: partial clone

On Friday 03 November 2017 at 01:32 pm -0700, Jonathan Tan wrote: > On Thu, 2 Nov 2017 20:31:17 + > Jeff Hostetler wrote: > > diff --git a/builtin/index-pack.c b/builtin/index-pack.c > > index a0a35e6..31cd5ba 100644 > > --- a/builtin/index-pack.c > > +++

[PATCH] t5580: add Cygwin support

for calculating the UNC path to the current directory. Instead use Cygwin's `cygpath` utility to get the Windows-style path. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- t/t5580-clone-push-unc.sh | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/t

Re: Test failure for v2.16.0-rc0 on cygwin

On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > Hi Junio, Adam, > > Just a quick note about the failure of the test-suite on cygwin. > In particular, test t5580-clone-push-unc.sh #3, like so: > > > > Adam, are you running the tests on Windows 10? I'm only routinely

Re: [PATCH v4 8/7] wildmatch test: skip file creation tests on Windows proper

On Wednesday 10 January 2018 at 04:07 pm +0700, Duy Nguyen wrote: > On Mon, Jan 08, 2018 at 01:25:04PM +0100, Johannes Schindelin wrote: > > I agree that it would make a ton of sense to use a proper, portable test > > framework written in pure, portable C. > > > > However, this ship has long

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

On Monday 25 December 2017 at 12:28 am +, Ævar Arnfjörð Bjarmason wrote: > There has never been any full roundtrip testing of what git-ls-files > and other functions that use wildmatch() actually do, rather we've > been satisfied with just testing the underlying C function. > > Due to

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

On Wednesday 03 January 2018 at 02:31 pm +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Jan 03 2018, Adam Dinwoodie jotted: > > > On Monday 25 December 2017 at 12:28 am +, Ævar Arnfjörð Bjarmason wrote: > >> There has never been any full roundtrip test

Re: [PATCH v3 22/23] cat-file: tests for new atoms added

On 12 February 2018 at 08:08, Olga Telezhnaya wrote: > Add some tests for new formatting atoms from ref-filter. > Some of new atoms are supported automatically, > some of them are expanded into empty string > (because they are useless for some types of objects), > some of them could be supported

Re: Test failure for v2.16.0-rc0 on cygwin

On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote: > On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > > Hi Junio, Adam, > > > > Just a quick note about the failure of the test-suite on cygwin. > > In particular, test t5580-cl

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

On Wednesday 03 January 2018 at 08:14 pm +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Jan 03 2018, Adam Dinwoodie jotted: > > > On Wednesday 03 January 2018 at 02:31 pm +0100, Ævar Arnfjörð Bjarmason > > wrote: > >> Does the fixup above in <878tdm8