On Tue, 21 May 2019 at 15:34, Nathan and Ila Reynolds wrote:
>
> I am not sure if this is the right mailing list. If not, please
> redirect me to the right place.
>
> I have Cygwin's git (2.21.0) and Git for Windows (2.21.0) installed on
> my Windows 10 machine. I run the following command with e
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 la
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 saile
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 <878tdm8k2d.
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 testing of wh
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 git-ls-f
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
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 testing
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
>
On Wednesday 22 November 2017 at 05:21 pm +0100, Christian Couder wrote:
> On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie wrote:
> > 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
>
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 `
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' th
his commit merely reduces those separate
steps to a single step.
Signed-off-by: Adam Dinwoodie
---
builtin/bisect--helper.c | 3 ++-
git-bisect.sh| 18 ++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/builtin/bisect--helper.c b/builtin/bisect--help
- I'm not entirely happy with the error handling, primarily as I
couldn't seem to 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 cha
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
---
git-bisect.sh | 9 -
1 file changed, 8
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.
Signe
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 with these two (and if I we
Add `git notes rm` and `git notes delete` as alternative ways of saying
`git notes remove`.
Signed-off-by: Adam Dinwoodie
---
Documentation/git-notes.txt | 4 +++-
builtin/notes.c | 8 +---
t/t3301-notes.sh| 6 +++---
3 files changed, 11 insertions(+), 7 deletions
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
Helped-by: Eric Sunshine
---
Documen
On Wednesday 08 November 2017 at 09:10 am -0500, Eric Sunshine wrote:
> On Wed, Nov 8, 2017 at 8:47 AM, Adam Dinwoodie wrote:
> > +e-mail discussions. Use of markers in addition to PATCH within
> > +the brackets to describe the nature of the patch is also
> > +encouraged.
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
> > +++ b/builtin/index-pack.c
> > @@ -222,6
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 ev
On Wednesday 08 November 2017 at 05:12 pm +0100, Christian Couder wrote:
> On Wed, Nov 8, 2017 at 2:59 PM, Adam Dinwoodie wrote:
> > +git bisect reset HEAD
>
> I guess that using "reset HEAD" could be cheaper than just "reset" and
> that's the reas
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
---
When I'm bisecting, I find I need to semi-regularly go back and c
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
---
I'm re-rolling this patch with some more substantive changes, as a bit
more resea
Signed-off-by: Adam Dinwoodie
---
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-rebase--interactive.sh
@@ -722,7
r the
closing bracket.
Signed-off-by: Adam Dinwoodie
---
Documentation/SubmittingPatches | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 558d465b6..e91ce8269 100644
--- a/Documentation/Submitt
On Wed, Nov 01, 2017 at 10:44:22AM +0900, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
> > t5580 tests that specifying Windows UNC paths works with Git. Cygwin
> > supports UNC paths, albeit only using forward slashes, not backslashes,
> > so run the compatible te
t suitable 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
---
t/t5580-clone-push-unc.sh | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/t/t5580-clone-
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.
>
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 s
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
---
Documentation/git.txt | 2 +-
1 file changed, 1 insertion
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 po
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.
> Th
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 "
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
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
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 fa
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.
F
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,
> > 867fa1d6a.
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 -i
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
> >
>
> We use Trav
(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 writes:
>
> > On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote:
> >> So I was wondering if there is a command th
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 wou
On Tue, Jun 06, 2017 at 08:55:04PM +0900, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
> > Digging briefly into the endianness detection, it appears Cygwin has
> > both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by
> > assuming it's
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 the
> > ifdefs gua
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
"Thanks-to" is not common usage, and should instead be "Helped-by".
Signed-off-by: Adam Dinwoodie
---
Documentation/SubmittingPatches | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 55
text, but the spaces 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
Helped-by: Jeff King
---
Documentation/git-pull.txt | 4 ++--
1 file changed, 2 insertions(
On Thu, Jun 01, 2017 at 11:06:18AM +0900, Junio C Hamano wrote:
> Jeff King 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
> >> space as {sp}.
formatted 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
---
Documentati
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
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:
> > >> [...]
> > >
> > >
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 picking
Add failing test case showing CRLF -> LF rewrite warnings being printed
multiple times when running "git commit".
Signed-off-by: Adam Dinwoodie
---
t/t0020-crlf.sh | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/t/t0020-crlf.sh b/t/t0020-
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 writes:
> >
> >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
> >> file that would have its line
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 once"
>From 50c9cbb6ce31529316ba004194f63a24ae59b4b0 Mon Sep 17 00:00:00 2001
From: Adam Dinwoodie
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-specific compatibility code in
[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 Cy
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
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
Signed-off-by: Adam Dinwoodie
---
This patch has previously been
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
> > unexpectedly p
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
test
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
g tests to show this behaviour.
Signed-off-by: Adam Dinwoodie
---
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 ed
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
---
I think the bug here is in usin
On Wed, Mar 16, 2016 at 07:34:07PM +, Eric Wong wrote:
> Adam Dinwoodie wrote:
> > According to the documentation, full URLs can be specified in the `-T`
> > argument to `git svn init`. However, the canonicalization of such
> > arguments squashes together co
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: 'svn:/svn.code.sf.net/p/squirr
process.
Signed-off-by: Adam Dinwoodie
---
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 rather than patching every
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:
> > >
>
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
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 el
appy
> and consider the flip of the default a good 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
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.
This is
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
/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
Signed-off-by: Adam Dinwoodie
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index
76 matches
Mail list logo
