Junio C Hamano pobox.com> writes:
>
> I would rather see us go in the direction to add "-z" output option,
> which is what everybody else that produces NUL terminated entries in
> our suite of subcommands does.
>
I agree that -z would help in this case and I very much appreciate that
option wh
Hello,
On your web-side http://git-scm.com I see following information
Latest stable release
1.8.5.5
Release Notes (2014-02-13)
When I click on the link Download for Windows the page
"http://git-scm.com/download/win"; is opened
and the download of file "Git-1.8.5.2-preview20131230.exe" start
Thomas Rast writes:
> Here's my moonshot:
>
> --- 8< ---
> Replace object loading/writing layer by libgit2
>
> Git reads objects from storage (loose and packed) through functions in
> sha1_file.c. Most commands only require very simple, opaque read and
> write access to the object storage. As a
On Thu, Feb 13, 2014 at 11:35:13AM -0800, Junio C Hamano wrote:
> >> test_normalize_tristate GIT_TEST_DAEMON
> >
> > Heh, great minds think alike. This is what I am playing with,
> > without committing (because I do like your "ask config if this is a
> > kind of various boolean 'false' represen
On Thu, Feb 13, 2014 at 06:17:17PM -0500, Ramkumar Ramachandra wrote:
> I'll throw in a few ideas from half-finished work.
Thanks. A few comments:
> 1. Speed up git-rebase--am.sh
>
> Currently, git-rebase--am.sh is really slow because it dumps each
> patch to a file using git-format-patch, and
Hello folks,
after some commits to my master branch, I tried to push to the bare upstream
repository and got this error message:
error: src refspec refs/heads/master matches more than one.
A quick check shows that there's indeed something wrong:
jw@kiste:/git/scan$ git branch -a | grep mast
On Thu, Feb 13, 2014 at 11:55:08AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > + if (need_generic_pathscan) {
> > + /* NOTE generic case also handles --stat, as it computes
> > +* diff(sha1,parent_i) for all i to do the job, specifically
> > +*
On Thu, Feb 13, 2014 at 11:51:19AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > + /* until we go to it next round, .next holds how many bytes we
> > +* allocated (for faster realloc - we don't need copying old
> > data).
> > +*/
> > + p-
Josef Wolf writes:
> Notice the refs/heads _within_ refs/heads!
>
> Now I wonder how I managed to get into this situation and what's the best way
> to recover?
Probably you did something like "git branch refs/heads/master". You can
remove it again with "git branch -d refs/heads/master".
Andrea
On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:
> Josef Wolf writes:
>
>> Notice the refs/heads _within_ refs/heads!
>>
>> Now I wonder how I managed to get into this situation and what's the best way
>> to recover?
>
> Probably you did something like "git branch refs/heads/master". You c
Attention
Sir,
Following an application brought, seeking the release of your due payment
through British bank, I am directed to inform you that the application has
been approved and Natwest bank of London has been mandated to make transfer
of your payment to the bank account you will nominate. Pl
The patch extends git config --file interface to allow read config from
stdin.
Signed-off-by: Kirill A. Shutemov
---
config.c | 10 ++
t/t1300-repo-config.sh | 4
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index d969a5aefc2b..f
On Wed, Feb 12, 2014 at 4:54 AM, Johan Herland wrote:
> Currently "git notes add -C $object" will read the raw bytes from $object,
> and then copy those bytes into the note object, which is hardcoded to be
> of type blob. This means that if the given $object is a non-blob (e.g.
> tree or commit),
On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:
> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:
> > Josef Wolf writes:
> >
> >> Notice the refs/heads _within_ refs/heads!
> > Probably you did something like "git branch refs/heads/master". You can
> > remove it again with "gi
Jeff King wrote:
>> 1. Speed up git-rebase--am.sh
>
> Isn't the merge backend faster? I thought that was the point of it.
I suppose, but I thought git-rebase--am.sh (the default flavor) could
be improved by leveraging relatively new cherry-pick features; I
assumed that the reason it was using form
Josef Wolf writes:
> On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:
>> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab
>> wrote:
>> > Josef Wolf writes:
>> >
>> >> Notice the refs/heads _within_ refs/heads!
>> > Probably you did something like "git branch refs/heads/master". You
Jeff King writes:
>> - We may want to do something similar in cvsserver and git-gui to
>>make them more robust.
>>
>>$ git grep -e true --and -e 1 --and -e yes
>
> I assume the "something" here is to respect bool options more
> consistently?
Yeah, mostly by employing your 'git -c magic
Eric Sunshine writes:
>> + if (type != OBJ_BLOB) {
>> + free(buf);
>> + die(_("Cannot read note data from non-blob object '%s'."),
>> arg);
>
> The way this diagnostic is worded, it sound as if the 'read' failed
> rather than that the user specified an incorrect
Øystein Walle writes:
> However, when specifying a format string it's just a matter of ending
> the format string in '%00' and you're good to go. But then you get the
> null byte *and* a newline. And with your proposal there would be no way
> of saying you want neither.
I very well understand th
Duy Nguyen writes:
> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab wrote:
>> Josef Wolf writes:
>>
>>> Notice the refs/heads _within_ refs/heads!
>>>
>>> Now I wonder how I managed to get into this situation and what's the best
>>> way
>>> to recover?
>>
>> Probably you did something like "g
Mail von Stefan-W. Hahn, Sun, 09 Feb 2014 at 12:01:55 +0100:
Good afternoon,
I updated the test a little bit. Test 3 and 7 are going wrong.
Both tests have a CRLF line ending in the changed line.
I you redirect the output of the test to a file you see the main
problem:
,
| -[32m+[m[32mZe
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab
>> wrote:
>>> Josef Wolf writes:
>>>
Notice the refs/heads _within_ refs/heads!
Now I wonder how I managed to get into this situation and what's the best
way
to recover?
On Fri, Feb 14, 2014 at 04:35:14PM +0100, David Kastrup wrote:
> Josef Wolf writes:
> > The only command in this script that uses "heads" is
> >
> > git symbolic-ref HEAD "refs/heads/$new_branch"
> >
> You probably should check how $new_branch comes about.
This is the line of code where $new_br
On Fri, Feb 14, 2014 at 10:30:28AM -0500, Ramkumar Ramachandra wrote:
> > Isn't the merge backend faster? I thought that was the point of it.
>
> I suppose, but I thought git-rebase--am.sh (the default flavor) could
> be improved by leveraging relatively new cherry-pick features; I
> assumed that
Kirill Smelkov writes:
> 8<
> From: Kirill Smelkov
> Subject: [PATCH v2 1/2] tree-diff: rework diff_tree() to generate diffs for
> multiparent cases as well
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
The last three do not belong he
On Thu, Feb 13, 2014 at 10:45 PM, Thomas Rast wrote:
> Replace object loading/writing layer by libgit2
>
> Git reads objects from storage (loose and packed) through functions in
> sha1_file.c. Most commands only require very simple, opaque read and
> write access to the object storage. As a weat
"Kirill A. Shutemov" writes:
> The patch extends git config --file interface to allow read config from
> stdin.
Thanks. The external interface proposed by this change that behaves
the way your new test expects is a good addition to the system. I
would describe it as:
Subject: config: teach
On Thu, Feb 13, 2014 at 04:10:37AM -0500, Jeff King wrote:
> The Google Summer of Code application process is upon us. We have about
> 34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very
> much time, but I know some people have been thinking about projects for
> a while, so I have
Hi everyone,
I noticed that git-reset does not seem to respect GIT_WORK_TREE. Here
is a simplified test case:
$ mkdir src_dir && cd src_dir
$ git init
$ touch A && git add A && git commit -m "Dummy commit."
$ mkdir ../build_dir && cd ../build_dir
$ export GIT_WORK_TREE=../src_dir
$ export GIT_DI
Am 14.02.2014 00:09, schrieb Zachary Turner:
> To elaborate a little bit more, you can verify with a sample program
> that ReadFile with OVERLAPPED does in fact modify the HANDLE's file
> position. The documentation doesn't actually state one way or
> another. My original attempt at a patch didn
On Thu, Feb 13, 2014 at 10:08:55AM +0100, Ephrim Khong wrote:
> Hi,
>
> for files that contain windows line endings in a repository with
> core.autocrlf=input, git blame will show lines as "Not Committed
> Yet", even though they were not modified.
>
> Example:
>
> --
> git init
> git config core
David Kastrup writes:
> Junio C Hamano writes:
> ...
>> A. Because it will confuse you.
>> B. I know what I am doing.
>> A. ???
>
> A. But maybe Git will no longer know what you are doing. Its standard
> way of resolving references will mean that once a branch
> refs/heads/wibble exists, ref
(Gah, sorry if you're receiving multiple emails to your personal
addresses, I need to get used to manually setting Plain-text mode
every time I send a message).
For the mixed read, we wouldn't be looking for another caller of
pread() (since it doesn't care what the file pointer is), but instead
a
git clone g...@github.com:ansible/ansible.git
git revert 3616dffb68badb2b8d56
manually solve the conflict (you can look at the commit here:
https://github.com/ansible/ansible/commit/3616dffb68badb2b8d56ef34391d7aae8de79cd6
)
git diff will output:
dario@macbook ~/P/ansible (devel*+|REVERTING)> gi
On Fri, Feb 14, 2014 at 10:21:35AM +0100, Peter Marx wrote:
> Hello,
>
> On your web-side http://git-scm.com I see following information
> Latest stable release
> 1.8.5.5
> Release Notes (2014-02-13)
>
> When I click on the link Download for Windows the page
> "http://git-scm.com/download/win"; i
On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
> * bc/gpg-sign-everywhere (2014-02-11) 9 commits
> - pull: add the --gpg-sign option.
> - rebase: add the --gpg-sign option
> - rebase: parse options in stuck-long mode
> - rebase: don't try to match -M option
> - rebase: remove
"brian m. carlson" writes:
>> Changes to some scripted Porcelains use unsafe variable
>> substitutions and still need to be tightened.
>>
>> Will merge to 'next'.
>
> Junio, did you want a reroll with that fixed commit message, or will you
> fix it up yourself?
I haven't merged them yet---if
From: Nicolas Vigier
There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-rebase.sh | 50 ++
1 file changed
From: Nicolas Vigier
Remove a check on the number of arguments for --onto and -x options.
It is not possible for $# to be <= 2 at this point :
- if --onto or -x has an argument, git rev-parse --parseopt will
provide something like this :
set -- --onto 'x' --
when parsing the "--onto"
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-rebase.txt | 4
git-rebase--am.sh| 8 +---
git-rebase--interactive.sh | 39 ++-
git-rebase--merge.sh | 2 +-
git-rebase
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-am.txt | 6 +-
git-am.sh| 9 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 54d8461.
From: Nicolas Vigier
There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-am.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
d
From: Nicolas Vigier
The -M option does not exist in OPTIONS_SPEC, so there is no use to try
to find it.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d183
git merge already allows us to sign commits, and git rebase has recently
learned how to do so as well. Teach git pull to parse the -S/--gpg-sign
option and pass this along to merge or rebase, as appropriate.
Signed-off-by: brian m. carlson
---
git-pull.sh | 13 -
1 file changed, 12
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-cherry-pick.txt | 7 ++-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 2 ++
sequencer.c | 11 +++
sequencer.h
From: Nicolas Vigier
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
contrib/git-resurrect.sh | 1 +
git-am.sh| 1 +
git-instaweb.sh | 1 +
g
On Fri, Feb 14, 2014 at 11:15 AM, Zachary Turner wrote:
> For the mixed read, we wouldn't be looking for another caller of pread()
> (since it doesn't care what the file pointer is), but instead a caller of
> read() or lseek(). In index-pack.c, I see two possible culprits:
>
> 1) A call to xread(
This series was posted to the list some time back. This is a re-send of
Nicolas Vigier's work with an additional patch that adds --gpg-sign to
pull as well, as well as the fixes that Junio suggested in review for
v3 and a typo noted in the v4 series.
There is also one additional merge call that w
On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
> As a workaround to make life easier for third-party tools, the
> upcoming major release will be called "Git 1.9.0" (not "Git 1.9").
> The first maintenance release for it will be "Git 1.9.1", and the
> major release after "Git 1.9.0"
Dario Bertini writes:
> git clone g...@github.com:ansible/ansible.git
> git revert 3616dffb68badb2b8d56
>
> manually solve the conflict (you can look at the commit here:
> https://github.com/ansible/ansible/commit/3616dffb68badb2b8d56ef34391d7aae8de79cd6
> )
>
> git diff will output:
>
> dario@ma
On Fri, Feb 14, 2014 at 10:27:11AM -0800, Junio C Hamano wrote:
> "Kirill A. Shutemov" writes:
>
> > The patch extends git config --file interface to allow read config from
> > stdin.
>
> Thanks. The external interface proposed by this change that behaves
> the way your new test expects is a go
Andrew Eikum writes:
> On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
>> As a workaround to make life easier for third-party tools, the
>> upcoming major release will be called "Git 1.9.0" (not "Git 1.9").
>> The first maintenance release for it will be "Git 1.9.1", and the
>> ma
"Kirill A. Shutemov" writes:
> On Fri, Feb 14, 2014 at 10:27:11AM -0800, Junio C Hamano wrote:
> ...
>> I recall that an earlier implementation of "git diff --no-index"
>> that made "-" read one side to be compared from the standard input
>> had exactly the same issue of comparing filename with "
On Fri, Feb 14, 2014 at 12:10:05PM -0800, Junio C Hamano wrote:
> Andrew Eikum writes:
>
> > On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote:
> >> As a workaround to make life easier for third-party tools, the
> >> upcoming major release will be called "Git 1.9.0" (not "Git 1.9").
Andrew Eikum writes:
> My worry is having "2." hang around for another decade or longer. I'd
> rather see X.0.0 denote a major feature release (currently represented
> as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix.
We need three categories: (1) potentially incompatible, (2) f
Mail von Stefan-W. Hahn, Sun, 09 Feb 2014 at 12:01:55 +0100:
Good afternoon,
I updated the test a little bit. Test 3 and 7 are going wrong.
Both tests have a CRLF line ending in the changed line.
I you redirect the output of the test to a file you see the main
problem:
,
| -[32m+[m[32mZe
Am 14.02.2014 17:47, schrieb Stefan-W. Hahn:
>> It's the right solution. IOW, you should place something like this in
>> your .gitattributes:
>> *.html whitespace=cr-at-eol
>
> Sorry, but this is not possible, because I have files of both sorts (mainly
> C/C++) files in my repository and cannot c
On Fri, Feb 14, 2014 at 01:08:32PM -0800, Junio C Hamano wrote:
> Andrew Eikum writes:
>
> > My worry is having "2." hang around for another decade or longer. I'd
> > rather see X.0.0 denote a major feature release (currently represented
> > as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z
From: Junio C Hamano
>
> These numerous questions you have to ask are indications why
> choosing "this condition goes to the left hand side of the equal
> sign (e.g. exists)" and "this condition goes to the right hand side
> (e.g. do-this-if_neighbor)" is not working well. The user has to
> remem
Christian Couder writes:
> For example some people might want:
>
> if_exists = overwrite
> if_missing = add
>
> while others might want:
>
> if_exists = overwrite
> if_missing = do_nothing
>
> and I don't see how we can say that with just:
>
> action = do_Y_if_X_and_Z
Yes, bu
Previously, git-completion.zsh redefined complete() to make __git_complete()
a no-op. This broke zsh's built-in bash completion compatibility layer
(bashcompinit), which defines its own complete().
Sadly, since there is no way in zsh to restore the original defintion of
complete() after bash-compl
On Fri, Feb 14, 2014 at 11:04 AM, Karsten Blees wrote:
>
> Damn...you're right, multi-threaded git-index-pack works fine, but some tests
> fail badly. Mixed reads would have to be from git_mmap, which is the only
> other caller of pread().
msysgit used git_mmap() as defined in compat/win32mmap.
The latest feature release Git v1.9.0 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
e60667fc16e5a5f1cde46616b0458cc802707743 git-1.9.0.tar.gz
65eb3f411f4699695c7081a7c716cabb9ce23d75
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'master' is v1.9.0. The first maintenance release for it
will be "Git 1.9.1", and the major release after "Git 1.9.0" will
either be
On Fri, Feb 14, 2014 at 08:32:07AM -0800, Junio C Hamano wrote:
> A. You are not allowed to call your branch with a string that begins with
> 'refs/heads/'.
> B. Why?
> A. Because it will confuse you.
> B. I know what I am doing.
> A. ???
Your reply in
http://git.661346.n2.nabble.com/1-8-
Junio C Hamano pobox.com> writes:
>
> I very well understand that. All other commands that support "-z"
> to give you NUL terminated output do not consider that a downside.
> Why should for-each-ref be special?
>
After I discovered log also has this there is nothing special about
for-each-ref
Am 14.02.2014 20:16, schrieb Zachary Turner:
> For the mixed read, we wouldn't be looking for another caller of
> pread() (since it doesn't care what the file pointer is), but instead
> a caller of read() or lseek() (since those do depend on the current
> file pointer). In index-pack.c, I see two
Øystein Walle writes:
> Maybe it's all subjective... I'm okay with just leaving things as they
> are.
Lack of "-z" in for-each-ref can be called an inconsistency that
already exists you may want to fix in any case.
As an extension to that, I would not be fundamentally against a new
option, e.g.
From: Junio C Hamano
>
> Christian Couder writes:
>
>> For example some people might want:
>>
>> if_exists = overwrite
>> if_missing = add
>>
>> while others might want:
>>
>> if_exists = overwrite
>> if_missing = do_nothing
>>
>> and I don't see how we can say that with just:
>>
The patch extends git config --file interface to allow read config from
stdin.
Editing stdin or setting value in stdin is an error.
Include by absolute path is allowed in stdin config, but not by relative
path.
Signed-off-by: Kirill A. Shutemov
---
builtin/config.c | 11 +
cac
The function will be reused to check for other conditions which prevent
write.
Signed-off-by: Kirill A. Shutemov
---
builtin/config.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 92ebf23f0a9a..a7c55e68883c 100644
We're going to have more options for config source.
Let's alter git_config_with_options() interface to accept struct with
all source options.
Signed-off-by: Kirill A. Shutemov
---
builtin/config.c | 75 ++--
cache.h | 8 --
confi
>> For example, how would you express something like this only with
>> "if-exists" vs "if-missing"?
>>
>> if_exists_exactly = ignore
>> if_exists_with_different_value = append
>> if_missng = prepend_to_the_beginning
>
> First, previously in the discussion you said that you did
Christian Couder writes:
> but we also want to say:
>
> action = do_Y_if_X_and_Z AND do_U_if_V
>
> For example some people might want:
>
> if_exists = overwrite
> if_missing = add
>
> while others might want:
>
> if_exists = overwrite
> if_missing = do_nothing
>
> and I don't
Junio C Hamano writes:
> That is, you are saying with the above
>
> if_exists = add_if_different AND ignore_if_same
>
> So you already have to support more than one actions depending on
> the condition, ...
> of conditions, I think. Which is essentially the same as saying
> that you need th
On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner wrote:
> (Gah, sorry if you're receiving multiple emails to your personal
> addresses, I need to get used to manually setting Plain-text mode
> every time I send a message).
>
> For the mixed read, we wouldn't be looking for another caller of
> pread
On Fri, Feb 14, 2014 at 4:45 PM, Duy Nguyen wrote:
> On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner wrote:
>> (Gah, sorry if you're receiving multiple emails to your personal
>> addresses, I need to get used to manually setting Plain-text mode
>> every time I send a message).
>>
>> For the mixed
On Sat, Feb 15, 2014 at 7:50 AM, Stefan Zager wrote:
> On Fri, Feb 14, 2014 at 4:45 PM, Duy Nguyen wrote:
>> On Sat, Feb 15, 2014 at 2:16 AM, Zachary Turner wrote:
>>> (Gah, sorry if you're receiving multiple emails to your personal
>>> addresses, I need to get used to manually setting Plain-tex
Even if we make that change to use TLS for this case, the
implementation of pread() will still change in such a way that the
semantics of pread() are different on Windows. Is that ok?
Just to summarize, here's the viable approaches I've seen discussed so far:
1) Use _WINVER at compile time to se
On Sat, Feb 15, 2014 at 8:15 AM, Zachary Turner wrote:
> Even if we make that change to use TLS for this case, the
> implementation of pread() will still change in such a way that the
> semantics of pread() are different on Windows. Is that ok?
>
> Just to summarize, here's the viable approaches
Since v1.8.4 (about six months ago) wildmatch is used as default
replacement for fnmatch. We have seen only one fix since so wildmatch
probably has done a good job as fnmatch replacement. This concludes
the fnmatch->wildmatch transition by no longer relying on fnmatch.
Signed-off-by: Nguyễn Thái N
Make it clear that we don't use fnmatch() anymore.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/apply.c| 2 +-
builtin/branch.c | 2 +-
builtin/describe.c | 2 +-
builtin/for-each-ref.c | 2 +-
builtin/ls-remote.c| 2 +-
builtin/name-rev.c | 2 +-
builtin/reflo
This reverts commit 1b25892636d2f250eb2163301440ee8c8c1ac944. compat
fnmatch will be removed soon and we can't rely on fnmatch() available
everywhere.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-wildmatch.c | 73
1 file changed, 73 deleti
Signed-off-by: Nguyễn Thái Ngọc Duy
---
compat/fnmatch/fnmatch.c (gone) | 494
compat/fnmatch/fnmatch.h (gone) | 84 ---
2 files changed, 578 deletions(-)
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c
deleted file mode 100644
index
Long story short, we wanted globbing wildcard "**" so I ripped
wildmatch library from rsync to do it. And it opened a possibility
to replace fnmatch completely, which would provide consistent behavior
across platforms (native fnmatch behaves differently on many corner
cases), and some performance g
Patterns in .gitattributes are separated by whitespaces, which makes
it impossible to specify exact spaces in the pattern. '?' can be used
as a workaround, but it matches other characters too. This patch makes
a space following a backslash part of the pattern, not a pattern
separator.
Signed-off-b
Mail von Johannes Sixt, Fri, 14 Feb 2014 at 22:19:03 +0100:
Good morning,
> Am 14.02.2014 17:47, schrieb Stefan-W. Hahn:
> >> It's the right solution. IOW, you should place something like this in
> >> your .gitattributes:
> >> *.html whitespace=cr-at-eol
> >
> > Sorry, but this is not possible,
87 matches
Mail list logo
