Hi Junio,
On Sun, 24 Jan 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The crucial idea hit me yesterday when I took a step back: all
> > we need to do is to ensure that the end-of-line style is matched
> > when *all* input files are LF-only, or when they are all CR/LF.
> > In
Hi Eric,
On Sun, 24 Jan 2016, Eric Sunshine wrote:
> On Sun, Jan 24, 2016 at 5:37 AM, Johannes Schindelin
> wrote:
> > On Fri, 22 Jan 2016, Eric Sunshine wrote:
> >> On Fri, Jan 22, 2016 at 2:50 PM, Eric Sunshine
> >> wrote:
> >> > On Fri, Jan 22, 2016 at 06:01:25PM +0100, Johannes Schindelin
Hi Philip,
On Sun, 24 Jan 2016, Philip Oakley wrote:
> From: "Johannes Schindelin"
> >From: 마누엘
>
> Is this Nalla's preferred email, or just a carry over from cautions of the
> Github interface?
Neither. It is from the author field as recorded in the commit that I
merged originally: https://g
Hi Torsten,
On Sun, 24 Jan 2016, Torsten Bögershausen wrote:
> On 24.01.16 11:48, Johannes Schindelin wrote:
> (I had the same reasoning about the CRLF in the working tree:
> We don't need to look at core.autocrlf/attributes, so Ack from me)
>
> > +test_expect_success 'conflict markers match exi
On Sun, Jan 24, 2016 at 9:03 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>> A string of the form "@/abcd" is considered a file path
>> by the msys layer and therefore translated to a Windows path.
>>
>> Here the trick is to double the slashes.
>>
>> The MSYS2 patch translation can be
On Fri, Jan 22, 2016 at 12:34 AM, Eric Sunshine wrote:
> On Tuesday, January 5, 2016, Karthik Nayak wrote:
>> Introduce the 'used_atom' structure to replace the existing
>> implementation of 'used_atom' (which is a list of atoms). This helps
>> us parse atoms beforehand and store required details
On Fri, Jan 22, 2016 at 1:17 AM, Eric Sunshine wrote:
> On Wed, Jan 6, 2016 at 2:27 AM, Karthik Nayak wrote:
>> On Wed, Jan 6, 2016 at 12:54 AM, Junio C Hamano wrote:
>>> Karthik Nayak writes:
while (slen) {
int len = slen;
+ const char *end = NULL
Hi all
It's pretty clear that code stored in a Git repository isn't considered a
derived work of Git, regardless of whether it is used in a commercial context
or otherwise.
However, I'm unable to find this stated in any authoritative and unambiguous
manner.
For example, http://www.sitepoint.c
Jeff King writes:
> Yeah, "strip=2" would also get the job done, and extends more naturally
> to the branch case.
>
> To be honest, I cannot imagine anybody using anything _but_ strip=2...
I 100% agree, and I do consider this to be internal implementation
detail for the listing modes of "tag" (a
Johannes Schindelin writes:
> Some of the tests expect that executable bits can be toggled, others
> expect that paths are POSIX paths (but when they come through git.exe,
> they are converted into Windows paths and necessarily differ), yet
> others expect symbolic links to be available.
These s
Johannes Schindelin writes:
> From: 마누엘
>
> Some git-svn tests expect that the executable bit of files can be
> toggled. On Windows, this is not possible because Windows' Access
> Control Lists are much more fine-grained than the POSIX permission
> concept. Let's just not try to flip the executa
On Sun, Jan 24, 2016 at 10:43 AM, Johannes Schindelin
wrote:
> When shell scripts access a $TMPDIR variable containing backslashes,
> they will be mistaken for escape characters. Let's not let that happen
> by converting them to forward slashes.
>
> This partially fixes t7800 with MSYS2.
>
> Signe
Johannes Schindelin writes:
> From: Pat Thoyts
>
> The test separator char is a colon which means any absolute paths on
> Windows confuse the tests that use global_excludes.
>
> Suggested-by: Karsten Blees
> Signed-off-by: Pat Thoyts
> Signed-off-by: Johannes Schindelin
> ---
> t/t0008-ignor
Johannes Schindelin writes:
> From: Thomas Braun
>
> A string of the form "@/abcd" is considered a file path
> by the msys layer and therefore translated to a Windows path.
>
> Here the trick is to double the slashes.
>
> The MSYS2 patch translation can be studied by calling
>
> test-path-
Johannes Schindelin writes:
> From: Karsten Blees
>
> The SVN library does not seem to support symlinks, even if symlinks are
> enabled in MSYS2 and Git. Use 'cp' instead of 'ln -s'.
>
> This partially fixes t/t9100-git-svn-basic.sh
>
> Signed-off-by: Karsten Blees
> Signed-off-by: Johannes Sch
Johannes Schindelin writes:
> This solves two problems:
>
> - we now have proper localisation even on Windows
>
> - we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)"
> message when running "git init" (which otherwise prevents the entire
> test suite from running)
It is u
Johannes Schindelin writes:
> This is a big milestone. With these modifications, Git's source code
> does not only build without warnings in Git for Windows' SDK, but
> passes the entire regression test suite.
;-)
It is somewhat surprising that with only these changes my tree is no
longer behin
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> A clean/smudge filter can be disabled if set to an empty string. However,
> Git will try to run the empty string as command which results in a error
> message per processed file.
The above two sentences do not make any sense to me. You
On Sun, Jan 24, 2016 at 5:27 PM, Jeff King wrote:
> On Sun, Jan 24, 2016 at 02:19:52PM -0800, Junio C Hamano wrote:
>> Perhaps strip=2 can be defined to "strip 2 levels of
>> hierarchy prefix no matter what that is", and strip refs/tags/foo,
>> refs/heads/foo and refs/remotes/origin/foo to foo, fo
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11),
git-tag has started showing tags with ambiguous names (i.e.,
when both "heads/foo" and "tags/foo" exists) as "tags/foo"
instead of just "foo". This is both:
- pointless; the output of "git tag" includes only
refs/tags, so we know tha
Because this script has to test so many formatters, we have
the nice "test_atom" helper, but we don't use it
consistently. Let's do so. This is shorter, gets rid of some
tests that have their "expected" setup outside of a
test_expect_success block, and lets us organize the changes
better (e.g., put
On Sun, Jan 24, 2016 at 02:19:52PM -0800, Junio C Hamano wrote:
> Also there is "what happens if the expected prefix is not there?"
> question. Perhaps strip=2 can be defined to "strip 2 levels of
> hierarchy prefix no matter what that is", and strip refs/tags/foo,
> refs/heads/foo and refs/remot
On Sun, Jan 24, 2016 at 02:19:52PM -0800, Junio C Hamano wrote:
> >> Instead, let's extend the "short" modifier in the formatting
> >> language to handle a specific prefix. This fixes "git tag",
> >> and lets users invoke the same behavior from their own
> >> custom formats (for "tag" or "for-each
Jeff King writes:
> On Sun, Jan 24, 2016 at 02:12:35AM -0500, Jeff King wrote:
>
>> In theory, the ref-filter code could figure this out by us
>> passing FILTER_REFS_TAGS. But there are two complications
>> there:
>>
>> 1. The handling of refname:short is deep in formatting
>> code that d
Johannes Sixt writes:
> Am 24.01.2016 um 11:56 schrieb Johannes Schindelin:
>> $ grep -w isalpha /mingw32/i686-w64-mingw32/include/*.h
>> /mingw32/i686-w64-mingw32/include/ctype.h: _CRTIMP int __cdecl isalpha(int
>> _C);
>> /mingw32/i686-w64-mingw32/include/ctype.h:#define __iscsymf(_c) (isalph
Johannes Schindelin writes:
> The crucial idea hit me yesterday when I took a step back: all
> we need to do is to ensure that the end-of-line style is matched
> when *all* input files are LF-only, or when they are all CR/LF.
> In all other cases, we have mixed line endings anyway.
>
> And to do
Junio C Hamano writes:
> Sorry, but I am confused by all of the above.
>
> We write the thing out with write_entry(), possibly applying smudge
> filters and eol conversion to the "git" representation to create the
> "working tree" representation in this codepath, right? The resulting
> file matc
On Sun, Jan 24, 2016 at 01:22:50PM +0100, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> A clean/smudge filter can be disabled if set to an empty string. However,
> Git will try to run the empty string as command which results in a error
> message per processed file.
>
> Teach Git t
On Sun, Jan 24, 2016 at 10:06 AM, Torsten Bögershausen wrote:
> On 24.01.16 13:22, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>> diff --git a/convert.c b/convert.c
>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src,
>> size_t len,
>> struct conv_attrs
Thomas Gummerer writes:
> My analysis is in the commit message below.
>
> --->8---
> Subject: [PATCH] entry: fix up to date marking
>
> write_entry always marks cache entries up to date when
> state->refresh_cache is set. This is however not always accurate,
> if core.autocrlf is set in the conf
Am 24.01.2016 um 16:44 schrieb Johannes Schindelin:
> On Windows, there are no POSIX paths, only Windows ones (an absolute
> Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under
> most circumstances, forward slashes are also allowed and synonymous to
> backslashes).
>
> So when
Disclaimer: Due to my currently very limited Git time budget I only
glanced over the recent discussion and patches. If you think I missed
something already discussed, I'd be happy being pointed to the relevant
discussion so I can catch up and avoid wasting everybody's time.
Am 23.01.2016 um 01:31
On Sun, Jan 24, 2016 at 5:37 AM, Johannes Schindelin
wrote:
> On Fri, 22 Jan 2016, Eric Sunshine wrote:
>> On Fri, Jan 22, 2016 at 2:50 PM, Eric Sunshine
>> wrote:
>> > On Fri, Jan 22, 2016 at 06:01:25PM +0100, Johannes Schindelin wrote:
>> >> +test_expect_success 'conflict markers contain CRLF
On Sat, Jan 23, 2016 at 1:31 AM, Stefan Beller wrote:
> We need the submodule groups in a later patch.
The commit message should now say "labels", too, I guess.
--
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.k
From: "Johannes Schindelin"
From: 마누엘
Is this Nalla's preferred email, or just a carry over from cautions of the
Github interface?
When the rename() function tries to move a directory it fails if the
target directory exists. It should check if it can delete the (possibly
empty) target di
On 24.01.16 17:27, Torsten Bögershausen wrote:
> On 24.01.16 11:48, Johannes Schindelin wrote:
> (I had the same reasoning about the CRLF in the working tree:
> We don't need to look at core.autocrlf/attributes, so Ack from me)
>
>> +test_expect_success 'conflict markers match existing line ending
On 24.01.16 11:48, Johannes Schindelin wrote:
(I had the same reasoning about the CRLF in the working tree:
We don't need to look at core.autocrlf/attributes, so Ack from me)
> +test_expect_success 'conflict markers match existing line endings' '
> + append_cr crlf-orig.txt &&
> + append_c
Right now, git archive creates a pax global header of the form
comment=57ca140635bf157354124e4e4b3c8e1bde2832f1
in tar archives it creates. This is suboptimal as as comments are
specified to be ignored by extraction software. It is impossible to
find out in an automatic way (short of guessing
MSYS2 actually allows to create files or directories whose names contain
tabs, newlines or colors, even if plain Win32 API cannot access them.
As we are using an MSYS2 bash to run the tests, such files or
directories are created successfully, but Git itself has no chance to
work with them because i
Some of the tests expect that executable bits can be toggled, others
expect that paths are POSIX paths (but when they come through git.exe,
they are converted into Windows paths and necessarily differ), yet
others expect symbolic links to be available.
This lets t9100-git-svn-basic.sh and t9130-gi
From: 마누엘
Some git-svn tests expect that the executable bit of files can be
toggled. On Windows, this is not possible because Windows' Access
Control Lists are much more fine-grained than the POSIX permission
concept. Let's just not try to flip the executable bit.
This lets t9118-git-svn-funky-b
From: Pat Thoyts
The test separator char is a colon which means any absolute paths on
Windows confuse the tests that use global_excludes.
Suggested-by: Karsten Blees
Signed-off-by: Pat Thoyts
Signed-off-by: Johannes Schindelin
---
t/t0008-ignores.sh | 8 +++-
1 file changed, 7 insertions
This test assumed that there is only one directory separator (the
forward slash), not two equivalent directory separators.
However, on Windows, the back slash and the forward slash *are*
equivalent.
Let's paper over this issue by converting the backward slashes to
forward ones in the test that fai
On Windows, there are no POSIX paths, only Windows ones (an absolute
Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under
most circumstances, forward slashes are also allowed and synonymous to
backslashes).
So when a POSIX shell (such as MSYS2's Bash, which is used by Git for
Wi
In Git for Windows' SDK, the tests are run using a Bash that relies on
the POSIX emulation layer MSYS2 (itself a friendly fork of Cygwin). As
such, paths in tests can be POSIX paths. As soon as those paths are
passed to git.exe (which does *not* use the POSIX emulation layer),
those paths are conve
From: Thomas Braun
A string of the form "@/abcd" is considered a file path
by the msys layer and therefore translated to a Windows path.
Here the trick is to double the slashes.
The MSYS2 patch translation can be studied by calling
test-path-utils print_path
Signed-off-by: Thomas Bra
From: Karsten Blees
The SVN library does not seem to support symlinks, even if symlinks are
enabled in MSYS2 and Git. Use 'cp' instead of 'ln -s'.
This partially fixes t/t9100-git-svn-basic.sh
Signed-off-by: Karsten Blees
Signed-off-by: Johannes Schindelin
---
t/t9100-git-svn-basic.sh | 9 ++
The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.
This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that POSIX
MSYS2 (the POSIX emulation layer used by Git for Windows' Bash) actually
has a working mkfifo. The only problem is that it is only emulating
named pipes through the MSYS2 runtime; The Win32 API has no idea about
named pipes, hence the Git executable cannot access those pipes either.
The symptom is
When shell scripts access a $TMPDIR variable containing backslashes,
they will be mistaken for escape characters. Let's not let that happen
by converting them to forward slashes.
This partially fixes t7800 with MSYS2.
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 23 ++
From: Karsten Blees
We will add more environment-related code to that new function
in the next patch.
Signed-off-by: Karsten Blees
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/compat/
This solves two problems:
- we now have proper localisation even on Windows
- we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)"
message when running "git init" (which otherwise prevents the entire
test suite from running)
The latter issue is rather crucial, as *no* test
On Windows, absolute paths never start with a slash, unless a POSIX
emulation layer is used. The latter is the case for MSYS2's Perl that
Git for Windows leverages. However, in the tests we also go through
plain `git.exe`, which does *not* leverage the POSIX emulation layer,
and therefore the paths
POSIX semantics requires lstat() to fail with ENOTDIR when "[a]
component of the path prefix names an existing file that is neither a
directory nor a symbolic link to a directory".
See http://pubs.opengroup.org/onlinepubs/9699919799/functions/lstat.html
This behavior is expected by t1404-update-r
It does not quite work because it produces DOS line endings which the
shell does not like at all.
This lets t0200-gettext-basic.sh, t0204-gettext-reencode-sanity.sh,
t3406-rebase-message.sh, t3903-stash.sh, t7400-submodule-basic.sh,
t7401-submodule-summary.sh, t7406-submodule-update.sh and
t7407-s
Since baaf233 (connect: improve check for plink to reduce false
positives, 2015-04-26), t5601 writes out a `plink.exe` for testing that
is actually a shell script. So the assumption that the `.exe` extension
implies that the file is *not* a shell script is now wrong.
Since there was no love for th
This is a big milestone. With these modifications, Git's source code
does not only build without warnings in Git for Windows' SDK, but
passes the entire regression test suite.
The patch series contains three different types of patches. First,
there are a couple of real fixes that were triggered by
From: 마누엘
When the rename() function tries to move a directory it fails if the
target directory exists. It should check if it can delete the (possibly
empty) target directory and then try again to move the directory.
This partially fixes t9100-git-svn-basic.sh.
Signed-off-by: 마누엘
Signed-off-by
On Sat, Jan 23, 2016 at 1:56 AM, Stefan Beller wrote:
> On Wed, Jan 20, 2016 at 1:59 AM, Christian Couder
> wrote:
>> When we know that mtime on directory the environment gives us is
>> usable for the purpose of untracked cache, we may want the
>> untracked cache to be always used by default with
Signed-off-by: Christian Couder
---
builtin/update-index.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 369c207..fe7aaa3 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1116,8 +1116,6 @@ int cmd_u
Factor out code into new_untracked_cache() and
add_untracked_cache(), which will be used
in later commits.
Helped-by: Eric Sunshine
Signed-off-by: Christian Couder
---
builtin/update-index.c | 11 +--
dir.c | 18 ++
dir.h | 1 +
3 files
To correctly perform its testing function,
test-dump-untracked-cache should not change the state of the
untracked cache in the index.
As a previous patch makes read_index_from() change the state of
the untracked cache and as test-dump-untracked-cache indirectly
calls this function, we need a mecha
Factor out code into remove_untracked_cache(), which will be used
in a later commit.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 6 +-
dir.c | 9 +
dir.h | 1 +
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/builtin/
Signed-off-by: Christian Couder
---
t/t7063-status-untracked-cache.sh | 85 +--
1 file changed, 81 insertions(+), 4 deletions(-)
diff --git a/t/t7063-status-untracked-cache.sh
b/t/t7063-status-untracked-cache.sh
index 253160a..a971884 100755
--- a/t/t7063-sta
Attempting to flip the untracked-cache feature on for a random index
file with
cd /random/unrelated/place
git --git-dir=/somewhere/else/.git update-index --untracked-cache
would not work as you might expect. Because flipping the feature on
in the index also records the location of the cor
It is not a good idea to compare kernel versions and disable
the untracked cache if it changes, as people may upgrade and
still want the untracked cache to work. So let's just
compare work tree locations and kernel name to decide if we
should disable it.
Also storing many locations in the ident fi
When we know that mtime on directory as given by the environment
is usable for the purpose of untracked cache, we may want the
untracked cache to be always used without any mtime test or
kernel name check being performed.
Also when we know that mtime is not usable for the purpose of
untracked cach
Helped-by: Duy Nguyen
Signed-off-by: Christian Couder
---
builtin/update-index.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index a6fff87..1e546a3 100644
--- a/builtin/update-index.c
+++ b/builtin/update
Here is a new version of a patch series to improve the untracked cache
feature.
This v7 implements core.untrackedCache as a tristate config
variable. When it's `true`, Git commands, especially `git status`,
should always add the untracked cache and use it, and when `false`,
Git commands should rem
It is nice to just be able to test if untracked cache is
supported without enabling it.
Helped-by: David Turner
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 12 +++-
builtin/update-index.c | 5 +
2 files changed, 16 insertions(+), 1 deletion(
Signed-off-by: Christian Couder
---
builtin/update-index.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 7431938..a6fff87 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1123,6 +1123,7 @@ int cmd_update_index(int arg
On 24.01.16 13:22, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
Some minor nits inside:
>
> A clean/smudge filter can be disabled if set to an empty string.
"set to an empty string" refers to "git config" (in opposite to the
filter as such, which is specified in .gitattributes.
Does i
On 01/22, Jeff King wrote:
> On Fri, Jan 22, 2016 at 12:52:55AM -0500, Jeff King wrote:
>
> > I get a few of the threads failing (in test 4) after 2-3 minutes. The
> > "-v" output is pretty unenlightening, though. I don't see anything
> > racy-looking in the test unless it is something with "read-t
With my patch, "git subtree split -P" produces the same result (for my
data set) as "git filter-branch --subdirectory-filter", which is much
faster, because it selects the revisions to rewrite before rewriting.
As I am not using any of the advanced features of "git subtree", I will
just use "git fi
Am 24.01.2016 um 11:56 schrieb Johannes Schindelin:
> $ grep -w isalpha /mingw32/i686-w64-mingw32/include/*.h
> /mingw32/i686-w64-mingw32/include/ctype.h: _CRTIMP int __cdecl isalpha(int
> _C);
> /mingw32/i686-w64-mingw32/include/ctype.h:#define __iscsymf(_c) (isalpha(_c)
> || ((_c)=='_'))
>
>
From: Lars Schneider
A clean/smudge filter can be disabled if set to an empty string. However,
Git will try to run the empty string as command which results in a error
message per processed file.
Teach Git to consider an empty clean/smudge filter as legitimately disabled
and do not print an erro
Hi Hannes,
On Sat, 23 Jan 2016, Johannes Sixt wrote:
> Am 23.01.2016 um 09:25 schrieb Johannes Schindelin:
>
> > On Fri, 22 Jan 2016, Junio C Hamano wrote:
> >
> > > Johannes Sixt writes:
> > >
> > > > I suggest to move the function definition out of line:
> > > >
> > > > diff --git a/compat/min
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected
The original patch was sent by Beat Bolli in
http://thread.gmane.org/gmane.comp.version-control.git/281600
My suggestion to extend it to respect gitattributes led to
changes that broke the original patch. And they were misguided
to begin with (see below).
Since there have been a couple of "What's
Hi Junio,
On Fri, 22 Jan 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> > It is the duty of ll_merge()'s *caller* (in case of Git's `merge`
> >> > command, the merge_content() function) to convert the merge result
> >> > into the correct working file contents, and ll_merge() s
Hi Junio,
On Fri, 22 Jan 2016, Johannes Schindelin wrote:
> On Fri, 22 Jan 2016, Junio C Hamano wrote:
>
> > Johannes Schindelin writes:
> >
> > > Signed-off-by: Johannes Schindelin
> > > ---
> >
> > This change somehow ringed a bell and reminded me of your recent
> > ls-files stuff. Are th
Hi Torsten,
On Sat, 23 Jan 2016, Torsten Bögershausen wrote:
> When path is NULL, can we set it to "*" to catch .gitattributes like
> "* text=auto"
> ?
The point of that part of the patch was to make things *independent* of
the gitattributes because we operate not on working files, but on blob
c
Hi Torsten,
On Sat, 23 Jan 2016, Torsten Bögershausen wrote:
> On 2016-01-22 18.01, Johannes Schindelin wrote:
> > From: Beat Bolli
> >
> > When merging files in repos with core.eol = crlf, git merge-file
> > inserts just a LF at the end of the merge markers. Files with mixed
> > line endings c
Hi Eric,
On Fri, 22 Jan 2016, Eric Sunshine wrote:
> On Fri, Jan 22, 2016 at 2:50 PM, Eric Sunshine
> wrote:
> > On Fri, Jan 22, 2016 at 06:01:25PM +0100, Johannes Schindelin wrote:
> >> +test_expect_success 'conflict markers contain CRLF when core.eol=crlf' '
> >> + test_must_fail git -c c
84 matches
Mail list logo
