On 7/28/19 6:49 PM, brian m. carlson wrote:> On 2019-07-28 at 22:10:29,
Pratyush Yadav wrote:
>> The function is not documented, and I only started spelunking the code a
>> couple days back, so I'll try to answer with what I know. It might
not be
>> the full picture.
>>
>> Running git-gui --tra
On 7/28/19 6:49 PM, brian m. carlson wrote:> On 2019-07-28 at 22:10:29,
Pratyush Yadav wrote:
>> The function is not documented, and I only started spelunking the code a
>> couple days back, so I'll try to answer with what I know. It might
not be
>> the full picture.
>>
>> Running git-gui --tra
On 7/28/19 6:49 PM, brian m. carlson wrote:> On 2019-07-28 at 22:10:29,
Pratyush Yadav wrote:
>> The function is not documented, and I only started spelunking the code a
>> couple days back, so I'll try to answer with what I know. It might
not be
>> the full picture.
>>
>> Running git-gui --tra
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 on Windows
shared directories, and is already enabled for the MinGW and plain
Windows builds.
This problem was reported on the Cygwin mailing
On 07/06/2015 03:40 PM, Junio C Hamano wrote:
If you are extending the history of some branch, then you would want
to be on that branch. Why would you want to have another worktree that
will get into a confusing state once you create that commit on the
checked out branch in this newly created w
On 06/30/2015 06:11 PM, Eric Sunshine wrote:
On Tue, Jun 30, 2015 at 12:56 AM, Eric Sunshine wrote:
The command "git checkout --to " is something of an anachronism,
encompassing functionality somewhere between "checkout" and "clone".
The introduction of the git-worktree command, however, provid
On 02/12/2015 06:51 PM, Jens Lehmann wrote:
Am 13.02.2015 um 11:57 schrieb Junio C Hamano:
Nguyễn Thái Ngọc Duy writes:
These patches are on top of what's in 'pu'. They add
--ignore-other-worktrees and make a note about current submodule
support status. I don't think submodule support is read
On 01/03/2015 04:41 AM, Nguyễn Thái Ngọc Duy wrote:
Noticed-by: Mark Levedahl
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-checkout.txt | 6 ++
builtin/checkout.c | 6 +-
t/t2025-checkout-to.sh | 7 +++
3 files changed, 18 insertions(+), 1
On 01/03/2015 04:41 AM, Nguyễn Thái Ngọc Duy wrote:
The goal seems to be using multiple checkouts to reduce disk space.
But we have not reached an agreement how things should be. There are a
couple options.
- You may want to keep $SUB repos elsewhere (perhaps in a central
place) outside $S
On 12/02/2014 12:30 PM, Junio C Hamano wrote:
Duy Nguyen writes:
FWIW git-branch usually can show the original branch of detached head
(must not always). I don't think we have a plumbing equivalent for it
though. People can "tail -1 $GIT_DIR/logs/HEAD| sed .." but that seems
hacky.
@{-1}, i.e
On 12/01/2014 12:39 PM, Junio C Hamano wrote:
Sorry, what is a hic? If this were an existing feature like
git-new-workdir, even though it is from contrib, making it impossible
to do something that used to be possible, even if that something is
what mere mortals would never want to to to avoid r
On 11/30/2014 03:24 AM, Nguyễn Thái Ngọc Duy wrote:
One branch obviously can't be checked out at two places (but detached
heads are ok). Give the user a choice in this case: --detach, -b
new-branch, switch branch in the other checkout first or simply 'cd'
and continue to work there.
This seems
On 11/28/2014 12:18 AM, Jeff King wrote:
On Thu, Nov 27, 2014 at 09:40:08AM -0500, Mark Levedahl wrote:
Then when you add new arguments, the hook has to search through the
parameters looking for one that matches, rather than just checking "$1"
for "amend" (and "$2&qu
On 11/25/2014 12:03 AM, Jeff King wrote:
On Mon, Nov 24, 2014 at 08:58:37PM -0800, Junio C Hamano wrote:
Jeff King writes:
1. It is a bit more obvious when debugging or dumping arguments (e.g.,
via GIT_TRACE), especially if new options are added after the
first.
2. It make
On 10/13/2014 01:19 PM, Junio C Hamano wrote:
Mark Levedahl writes:
Some options may be configured globally for a remote (e.g, tagopt).
Or some remotes may have only pushurl and not url. "git remote"
output for me has a few such remotes but wouldn't this patch break
it?
I
t packed-refs ; find refs/ -type f) \
2>/dev/null | sed -ne 's@^.*refs/@refs/@p' | sort | uniq
real0m0.012s
user0m0.006s
sys 0m0.005s
So, this is a win even on Linux, but more importantly it makes use of
tab completion tolerable on Cygwin when symlinks are involved
t;git fetch --all" or "git remote
update."
Signed-off-by: Mark Levedahl
---
remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index ce785f8..1b08924 100644
--- a/remote.c
+++ b/remote.c
@@ -761,7 +761,7 @@ int for_each_remote(each_remo
On 08/08/2013 01:44 PM, Ramsay Jones wrote:
Fredrik Gustafsson wrote:
On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote:
But we'll have to use sm_path here (like everywhere else in the
submodule script), because we'll run into problems under Windows
otherwise (see 64394e3ae9 for deta
On 08/01/2013 05:12 PM, Junio C Hamano wrote:
Ramsay Jones writes:
Junio C Hamano wrote:
Ramsay Jones writes:
I am personally in favor of this simpler solution. Comments?
I had expected this to me marked for 'master'.
Has this simply been overlooked, or do you have reservations about
On 07/22/2013 01:02 AM, Junio C Hamano wrote:
b) The Cygwin project has always shipped git binaries built without
NO_TRUSTABLE_FILEMODE
That is a fair point. So let's do this instead.
-- >8 --
From: Mark Levedahl
Subject: [PATCH] cygwin: stop forcing core.filemode=false
On 07/21/2013 05:56 PM, Junio C Hamano wrote:
Ramsay Jones writes:
Mark Levedahl wrote:
The supported Cygwin distribution on supported Windows versions provides
complete support for POSIX filemodes, so enable this by default.
...
Historical notes: Cygwin version 1.7 supports Windows-XP and
On 07/19/2013 03:16 PM, Junio C Hamano wrote:
Mark Levedahl writes:
Related: Should we have separate settings for 1.5 and 1.7 for several
variables? Conflicts I see not reflected in config.mak.uname on pu:
trustable filemode (1.7 has, 1.5 does not)
MMAP/Pread (1.7 pread is thread
git has shipped for years with MMAP enabled in the stock distribution,
there are no reports of problems / failures on the list relating to
this. Leave the default as-is on v1.5 due to lack of knowlege of this
working on earlier Cygwin.
Signed-off-by: Mark Levedahl
---
config.mak.uname | 8
1.5. Thus, POSIX filemode support
is not expected by default on a Cygwin 1.5 installation, but is expected
by default on a 1.7 installation.
Signed-off-by: Mark Levedahl
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname b/config.mak.uname
Cygwin v1.7 uses the regex library from newlib which does not pass git's
tests, so don't use it. This fixes failures in t4018 and t4034.
Continue to use the platform supplied regex library for earlier versions.
Signed-off-by: Mark Levedahl
---
config.mak.uname | 2 ++
1 file
Per http://cygwin.com/ml/cygwin/2012-07/msg00331.html , cygwin 1.7
was modified to explicitly support git's use of pread, so make this
the default. Do not affect earlier cygwin versions.
Signed-off-by: Mark Levedahl
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 del
On 07/19/2013 12:40 PM, Junio C Hamano wrote:
Thanks, will replace.
What do we want to do with the compat/regex build-time switch?
IIRC, this was only needed for 1.7 and not 1.5, and I also would
expect (without anything to back-up, so this is more a faith than
expectation) over time the "new l
On 07/18/2013 07:32 PM, Junio C Hamano wrote:
Mark Levedahl writes:
Unlike the results on the fast Win7 laptop, the above show
statistically significant slow down from the fast_lstat approach. I'm
just not seeing a case for the special case handling, and of course
Junio has already voted
is
expected by default on a 1.7 installation.
Signed-off-by: Mark Levedahl
---
Junio - The above notes are more accurate than in my previous commit message,
so if this commit survives into next/master, I would prefer this version as
opposed to the one now on pu (da875762)
Mark
config.mak.uname
On 07/18/2013 05:49 PM, Torsten Bögershausen wrote:
On 2013-07-18 19.50, Ramsay Jones wrote:
Hmm, that looks good. :-D
Torsten reported a performance boost using the win32 stat() implementation
on a linux git repo (2s -> 1s, if I recall correctly) on cygwin 1.7.
Do you have a larger repo avail
Define a common macro for grep needing -U to allow tests to not need
to inquire of specific platforms needing this option. Change
t3032 and t5560 to use this rather than testing explicitly for mingw.
This fixes these two tests on Cygwin.
Signed-off-by: Mark Levedahl
---
This replaces my earlier
On 07/18/2013 03:19 PM, Ramsay Jones wrote:
Jonathan Nieder wrote:
Mark Levedahl wrote:
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is
This test fails on Cygwin where the default system configuration does not
support case sensitivity (only case retention), so don't run the test on
such systems.
Signed-off-by: Mark Levedahl
---
t/t6131-pathspec-icase.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/
On 07/16/2013 05:41 PM, Ramsay Jones wrote:
Mark Levedahl wrote:
Cygwin's regex library does not pass git's tests, so don't use it. This
fixes failures in t4018 and t4034.
Hmm, these tests have always passed for me on cygwin. So, this is
presumably a regression in the new-li
On 07/16/2013 05:20 PM, Ramsay Jones wrote:
Mark Levedahl wrote:
The supported Cygwin distribution on supported Windows versions provides
complete support for POSIX filemodes, so enable this by default. git as
distributed by the Cygwin project is configured this way.
This fixes one testsuite
On 07/16/2013 05:36 PM, Ramsay Jones wrote:
Caveats:
1) I don't find any speed improvement of the current patch over the
previous one (the tests actually ran faster with the earlier patch,
though the difference was less than 1%).
2) I still question this whole approach, especially having this
non
On 07/16/2013 11:42 AM, Dmitry Potapov wrote:
On Tue, Jul 16, 2013 at 7:54 AM, Mark Levedahl wrote:
I see no difference in the above. (Yes, I checked multiple times that I was
using different executables).
Are you sure that you set core.filemode to false before testing?
yes.
--
To
On 07/16/2013 05:41 PM, Ramsay Jones wrote:
Mark Levedahl wrote:
Cygwin's regex library does not pass git's tests, so don't use it. This
fixes failures in t4018 and t4034.
Hmm, these tests have always passed for me on cygwin. So, this is
presumably a regression in the new-li
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. These tests create and test for
lines ending in \r\n, but as this is a valid line separator on Windows,
convert such lines in the output to avoid confusion by line-oriented
grep.
Signed-off-by: Mark
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. These tests create and test for
lines ending in \r\n, but as this is a valid line separator on Windows,
convert such lines in the output to avoid confusion by line-oriented
grep.
Signed-off-by: Mark
On 07/16/2013 02:59 PM, Jonathan Nieder wrote:
Mark Levedahl wrote:
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is not changed when
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is not changed when being extracted by line oriented grep.
Signed-off-by: Mark Levedahl
Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail on
msysgit for similar reasons. Looking at test 6, the expected result is a
line ending with \r\n in text.txt. This line is extracted with grep
(grep 'justice and holiness' text.txt > actual), with unavoidable result
that on C
On 07/15/2013 10:06 PM, Torsten Bögershausen wrote:
On 2013-07-15 21.49, Junio C Hamano wrote:
Mark Levedahl writes:
In order to limit the adverse effects caused by this implementation,
we provide a new "fast stat" interface, which allows us to use this
only for interactions with
On 07/15/2013 03:49 PM, Junio C Hamano wrote:
Mark Levedahl writes:
In order to limit the adverse effects caused by this implementation,
we provide a new "fast stat" interface, which allows us to use this
only for interactions with the index (i.e. the cached stat data).
Signed-off-
On 07/15/2013 06:06 PM, Junio C Hamano wrote:
Mark Levedahl writes:
cvs v1.12 does not correctly handle "cvs co -d $DIR", which is shorthand
for "mkdir $DIR, cd $DIR, cvs co, cd -". So, use the latter form.
Hmph, I think I've been using 1.12.13 and without seeing
iminate
checking CVS/Entries for this one test, but keep the test that the
created file exists and is checked out.
With these changes, all tests in t9200 pass on Cygwin using its default
cvs version 1.12.
Signed-off-by: Mark Levedahl
---
t/t9200-git-cvsexportcommit.sh | 4 ++--
1 file changed, 2 insert
Cygwin's regex library does not pass git's tests, so don't use it. This
fixes failures in t4018 and t4034.
Signed-off-by: Mark Levedahl
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index 7ac541e..69015
On 07/10/2013 04:23 PM, Ramsay Jones wrote:
Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008)
added a Win32 specific implementation of the stat functions. In order
to handle absolute paths, cygwin mount points and symbolic links, this
implementation may fall back on the standa
such support), but as this is no different than Linux, the
default should not treat Cygwin differently than Linux.
Users who desire the non-POSIX mode of operation must explicitly set
core.filemode=False, accepting non-interoperability with Linux.
Signed-off-by: Mark Levedahl
On 07/13/2013 08:57 PM, Jonathan Nieder wrote:
I'm not sure I follow. Are you saying Windows users would never want
to access Subversion repositories? Thanks, Jonathan
Quite the contrary. SVN and git both work on Windows without having
POSIX FIFOs - Windows does have FIFOS, but the semantics a
On 07/12/2013 08:42 AM, Mikko Rapeli wrote:
(please Cc: me in replies, not subscribed to the lists)
Hi Cygwin and git developers,
Does following scenario show signs of bugs in Cygwin and/or git?
# setup git repo
$ cd /tmp
$ mkdir foo && cd foo
$ git init
# create x: directory
$ mkdir x:
$ ls
On 07/06/2013 08:55 PM, Jonathan Nieder wrote:
Mark Levedahl wrote:
Do not use FIFOs on cygwin, they do not work. Cygwin includes
coreutils, so has mkfifo, and that command does something. However,
the resultant named pipe is known (on the Cygwin mailing list at
least) to not work correctly
tests in that file work correctly).
Signed-off-by: Mark Levedahl
---
t/test-lib.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 9753641..2d63307 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -885,7 +885,14 @@ test_i18ngrep
On 06/27/2013 01:38 PM, Junio C Hamano wrote:
Torsten Bögershausen writes:
Work around issues that git hangs when doing fetch or pull under
various protocols under CYGWIN.
Replace pipe() with a socket connection using a TCP/IP.
Introduce a new function socket_pipe() in compat/socket_pipe.c
S
On 06/27/2013 06:58 PM, Ramsay Jones wrote:
This is why I tried the "cygwin: Remove the Win32 l/stat()
functions" patch first; I think this is the correct approach
to fixing this problem (and similar *future* problems).
I adamantly agree.
However, since that is no longer an option, on performa
On 06/26/2013 10:19 AM, Torsten Bögershausen wrote:
On 2013-06-25 23.18, Junio C Hamano wrote:
Johannes Sixt writes:
Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
patch in pu?
Sure. Thanks.
First of al
On 05/07/2013 10:27 AM, Torsten Bögershausen wrote:
On 2013-05-04 01.14, Junio C Hamano wrote:
Cygwin portability; both were reviewed by Jonathan, and the tip one
seems to want a bit further explanation. Needs positive report
from Cygwin 1.7 users who have been on 1.7 to make sure it doe
On 02/25/2013 01:44 AM, Junio C Hamano wrote:
I was in "find leftover bits" mode today and found this thread
hanging. Has anything come out of this thread, or there is nothing to
improve in this area?
The patch passed my simple tests (build, run a few commands), but I
didn't get around to a
On 01/25/2013 08:03 PM, Jonathan Nieder wrote:
diff --git a/abspath.c b/abspath.c
index 40cdc462..c7d5458e 100644
--- a/abspath.c
+++ b/abspath.c
@@ -216,7 +216,7 @@ const char *absolute_path(const char *path)
const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
{
On 01/22/2013 01:31 PM, Ramsay Jones wrote:
include order. ;-) As I have mentioned here before, the claim that
"WIN32 is not defined on cygwin" is simply nonsense - it depends on
if/when certain header files are included. For example, *as soon as*
you include (and, I suspect, many other win32
On 01/11/2013 03:17 PM, Alex Riesen wrote:
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen wrote:
This short discussion on GitHub (file git-compat-util.h) might be relevant:
https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
The change suggested
On 01/07/2013 02:29 AM, Junio C Hamano wrote:
I do not have much stake in this personally, but IIRC, the (l)stat
workaround was back then found to make Cygwin version from "unusably
slow" to "slow but torelable", as our POSIX-y codebase assumes that
lstat is fairly efficient, which Cygwin cannot
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by having dll version 1.7
On 01/06/2013 04:35 PM, Junio C Hamano wrote:
Thanks; so perhaps you can give me an OK to forge your S-o-b to the
following?
-- >8 --
From: Mark Levedahl
Date: Sun, 6 Jan 2013 11:56:33 -0800
Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
There is no documented, reliable,
On 01/06/2013 03:51 PM, Torsten Bögershausen wrote:
Hm, I haven't understood the connection between the dll (cygwin1.dll
?) which is used in runtime, and the header files which are used when
compiling. Are they updated at the same time when updating from 1.7.16
to 1.7.17 ? Until I updated my cy
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by having dll version 1.7
On 01/06/2013 04:57 AM, Jonathan Nieder wrote:
Torsten Bögershausen wrote:
The short version:
Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
[...]
I don't know if we want to improve the Makefile to enable
CYGWIN_V15_WIN32API = YesPlease
for cygwin versions 1.7.1 .
On 12/19/2012 02:59 AM, Erik Faye-Lund wrote:
On Tue, Dec 18, 2012 at 6:01 PM, Junio C Hamano wrote:
Johannes Sixt writes:
Junio C Hamano wrote:
It could turn out that we may be able to get rid of sys/param.h
altogether, but one step at a time. Inputs from people on minority
platforms are
The previous macro was confusing to some, and did not include "cygwin" in
its name. The updated name more clearly expresses a choice of the
win32api implementation that shipped with version 1.5 of cygwin.
Signed-off-by: Mark Levedahl
---
Makefile| 6 +++---
compat/cygwin.c
On 11/17/2012 02:09 AM, Torsten Bögershausen wrote:
See commit 380a4d927bff693c42fc6b22c3547bdcaac4bdc3:
"Update cygwin.c for new mingw-64 win32 api headers"
Cygwin up to 1.7.16 uses some header file from the WINE project
Cygwin 1.7.17 uses some header file from the mingw-64 project
As the old cy
On 11/15/2012 02:35 PM, Torsten Bögershausen wrote:
On 11/15/2012 08:05 PM, Ramsay Jones wrote:
Did the cygwin project not bump an api version number somewhere?
ATB,
Ramsay Jones
Ramsay,
you can run uname -r to see the version number.
I myself haven't fully understood all the consequences,
s
On 11/14/2012 07:16 PM, Jeff King wrote:
On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote:
b) Autodetection:
(Just loud thinking), running
$grep mingw /usr/include/w32api/winsock2.h
* This file is part of the mingw-w64 runtime package.
#include <_mingw_unicode.h>
on cygw
On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:
* ml/cygwin-mingw-headers (2012-11-12) 1 commit
- Update cygwin.c for new mingw-64 win32 api headers
Make git work on newer cygwin.
Will merge to 'next'.
(Sorry for late answer, I managed to test the original patch minutes before
Peff
On Mon, Nov 12, 2012 at 3:58 PM, Jeff King wrote:
> On Sun, Nov 11, 2012 at 07:17:20PM -0500, Mark Levedahl wrote:
>
>> The cygwin project recently switched to a new implementation of the
>> windows api, now using header files from the mingw-64 project. These
>> new heade
cygwin.c to use the new include ordering only if
the dll version is 1.7 or higher.
Signed-off-by: Mark Levedahl
---
Makefile| 4
compat/cygwin.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..1cc5d96 100644
--- a/Makefile
+++ b/Makefile
76 matches
Mail list logo
