Am 29.01.2016 um 02:41 schrieb Eric Wong:
Junio C Hamano wrote:
Eric Wong writes:
getaddrinfo() may return multiple addresses, not all of which
are equally performant. In some cases, a user behind a non-IPv6
capable network may get an IPv6 address which stalls connect().
Instead of waiting
Good day!
Software.informer.com would like to inform you that your product GIT 2.7.0 has
been reviewed by our editors and your program got "100% Clean Award"
http://git.software.informer.com/.
We would be grateful if you place our award with a link to our review on your
website. On our part, w
On Fri, Jan 29, 2016 at 1:18 AM, Eric Sunshine wrote:
> On Thu, Jan 28, 2016 at 6:56 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> When we detect the pattern is just a literal string, we avoid heavy
>> regex engine and use fast substring search implemented in kwsset.c.
>> But kws uses git-ctype which is
On Thu, Jan 28, 2016 at 6:56 AM, Nguyễn Thái Ngọc Duy wrote:
> Similar to the "grep -F -i" case, we can't use kws on icase search
> outside ascii range, so we quote the string and pass it to regcomp as
> a basic regexp and let regex engine deal with case sensitivity.
>
> The new test is put in t78
On Thu, Jan 28, 2016 at 6:56 AM, Nguyễn Thái Ngọc Duy wrote:
> Similar to the previous commit, we can't use kws on icase search
> outside ascii range. But we can't simply pass the pattern to
> regcomp/pcre like the previous commit because it may contain regex
> special characters, so we need to qu
On Thu, Jan 28, 2016 at 6:56 AM, Nguyễn Thái Ngọc Duy wrote:
> When we detect the pattern is just a literal string, we avoid heavy
> regex engine and use fast substring search implemented in kwsset.c.
> But kws uses git-ctype which is locale-independent so it does not know
> how to fold case prope
On Thu, Jan 28, 2016 at 02:46:40PM +, Anatoly Borodin wrote:
> The `git replace` makes the second commit empty (use the file content from
> the first commit). It should disappear after `git filter-branch`, but it
> doesn't happen.
>
> Bug 1: the empty commit stays.
I'm not sure if this is a
On 2016-01-29 04.04, Junio C Hamano wrote:
> Eric Wong writes:
>
>> getaddrinfo() may return multiple addresses, not all of which
>> are equally performant. In some cases, a user behind a non-IPv6
>> capable network may get an IPv6 address which stalls connect().
>
> I'd assume that you are not
On Thu, Jan 28, 2016 at 05:17:36PM -0500, Stefan Monnier wrote:
> I recently discovered that "git fast-import" signals an error if used in
> a tree to which we do not have write-access, because it tries to create
> a "objects/pack/tmp_pack_XXX" file even before starting to process
> the commands.
On Thu, Jan 28, 2016 at 06:56:16PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/test-regex.c b/test-regex.c
> @@ -1,19 +1,63 @@
> int main(int argc, char **argv)
> {
> - char *pat = "[^={} \t]+";
> - char *str = "={}\nfred";
> + const
Dear Sir/Madam,
Clean tested working pulls CPUs and QTYs in stock.
115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690
Brand new sealed IP phones and QTYs in stock.
55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x A
On Thu, Jan 28, 2016 at 07:19:30PM -0800, Junio C Hamano wrote:
> I just reviewed the output that are protected by CONNECT_VERBOSE;
> they look somewhere between pure debugging aid (like the protocol
> dump that are shown by "fetch -vv") and progress display, and at
> least to me they are much clo
Eric Wong writes:
> On the other hand, I'm not sure if there's anything parsing the stderr
> out of "git fetch -v" right now.
It would also affect end-user experience, depending on what new
pieces of lines are emitted to the terminal. From "git fetch -v", I
expect to see the transfer progress a
I couldn't find any other examples of people referring to this character
as a "blank".
Signed-off-by: Alex Henrie
---
builtin/stripspace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index 7ff8434..15e716e 100644
--- a/builtin/s
Sorry, wrong patch...this issue has already been fixed
-Alex
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
`git blame 22414770 generate-cmdlist.perl` currently results in:
fatal: cannot stat path '22414770': No such file or directory
This patch changes the error message to:
fatal: ambiguous argument 'generate-cmdlist.perl': unknown revision
or path not in the working tree.
Use '--' to s
Eric Wong writes:
> getaddrinfo() may return multiple addresses, not all of which
> are equally performant. In some cases, a user behind a non-IPv6
> capable network may get an IPv6 address which stalls connect().
I'd assume that you are not solving a hypothetical problem, but you
may (at least
When invoking default (g)vimdiff three-way merge, the merged file is
loaded as the first buffer but moved to the bottom as the fourth window.
This causes a disconnect between vim commands that operate on window
positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.
do/dp).
This cha
Junio C Hamano wrote:
> Eric Wong writes:
>
> > getaddrinfo() may return multiple addresses, not all of which
> > are equally performant. In some cases, a user behind a non-IPv6
> > capable network may get an IPv6 address which stalls connect().
> > Instead of waiting synchronously for a connec
Jeff King wrote:
> On Thu, Jan 28, 2016 at 10:51:23PM +, Eric Wong wrote:
> > -static int connect_setup(struct transport *transport, int for_push, int
> > verbose)
> > +static int connect_setup(struct transport *transport, int for_push)
> > {
> > struct git_transport_data *data = transpo
Nguyễn Thái Ngọc Duy writes:
> The series fixes grep choosing fast path that only works correctly for
> ascii. This is a resend of v4 [1] after rebase. I think v4 just went
> off radar for some reason, nothing was wrong with it (or nobody told
> me about it).
Or nobody found it interesting, per
On Thu, Jan 28, 2016 at 10:51:23PM +, Eric Wong wrote:
> While working in connect.c to perform non-blocking connections,
> I noticed calling "git fetch -v" was not causing the progress
> messages inside git_tcp_connect_sock to be emitted as I
> expected.
>
> Looking at history, it seems conne
larsxschnei...@gmail.com writes:
> - if (ca.drv) {
> + if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
You are not interested in its length, but if it is an empty string
or not, so I'd tweak this like so:
> + if (ca.drv && ca.drv->smudge && *ca.drv->smudge) {
--
To unsubsc
Eric Wong writes:
> While working in connect.c to perform non-blocking connections,
> I noticed calling "git fetch -v" was not causing the progress
> messages inside git_tcp_connect_sock to be emitted as I
> expected.
Nice. Can we demonstrate and protect this fix with simple tests?
Thanks. Wi
Eric Wong writes:
> getaddrinfo() may return multiple addresses, not all of which
> are equally performant. In some cases, a user behind a non-IPv6
> capable network may get an IPv6 address which stalls connect().
> Instead of waiting synchronously for a connect() to timeout, use
> non-blocking
On 28 January 2016 at 21:41, Stefan Beller wrote:
> On Thu, Jan 28, 2016 at 1:25 PM, Matthias Aßhauer wrote:
https://github.com/git/git/pull/191
>>>
>>> Oh I see you're using the pull-request to email translator, cool!
Yay!
>> Yes, I did. It definitly makes things easier if you are not use
Andrew Wheeler writes:
> diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
> index c402d8d..c65033f 100755
> --- a/t/t5533-push-cas.sh
> +++ b/t/t5533-push-cas.sh
> @@ -101,7 +101,8 @@ test_expect_success 'push to update (allowed, tracking)' '
> (
> cd dst &&
>
Matthias Asshauer writes:
> From: Matthias Aßhauer
>
> This patch implements a new "git stash--helper" builtin plumbing
> command that will be used to migrate "git-stash.sh" to C.
>
> We start by implementing only the "--non-patch" option that will
> handle the core part of the non-patch stashin
While working in connect.c to perform non-blocking connections,
I noticed calling "git fetch -v" was not causing the progress
messages inside git_tcp_connect_sock to be emitted as I
expected.
Looking at history, it seems connect_setup has never been called
with the verbose parameter. Since transp
I recently discovered that "git fast-import" signals an error if used in
a tree to which we do not have write-access, because it tries to create
a "objects/pack/tmp_pack_XXX" file even before starting to process
the commands.
Usually this is not a problem (we'll create new commits and such, so
wri
On Thu, Jan 28, 2016 at 2:03 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +static char *relative_url(const char *remote_url,
>> + const char *url,
>> + const char *up_path)
>> +{
>> + int is_relative = 0;
>> + int colonsep
Lars Schneider writes:
> If the clean/smudge command of a Git filter driver (filter..smudge and
> filter..clean) is set to an empty string ("") and the filter driver is
> not required (filter..required=false) then Git will run successfully.
> However, Git will print an error for every file that i
Stefan Beller writes:
> +static char *relative_url(const char *remote_url,
> + const char *url,
> + const char *up_path)
> +{
> + int is_relative = 0;
> + int colonsep = 0;
> + char *out;
> + char *remoteurl = xstrdup(remote_
On Thu, Jan 28, 2016 at 1:25 PM, Matthias Aßhauer wrote:
>> You had some good measurements in the coverletter, which is not going to be
>> recorded in the projects history. This part however would be part of the
>> commit.
>> So you could move the speed improvements here (as well as the other
>
Johannes Schindelin writes:
>> For what it's worth, I ran the test suite on Mac OS X and FreeBSD, as
>> well, with this series applied and didn't run across any problems. I
>> also read through v3 and, other than the micro nit in patch 11/20,
>> didn't find anything upon which to comment.
>
> Tha
Johannes Schindelin writes:
>> > diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
>> > @@ -23,6 +23,11 @@ then
>> > +if ! test_have_prereq PIPE
>>
>> Maybe:
>>
>> if test_have_prereq !PIPE
>>
>> ?
>
> Darn. Of course I only looked for '! .*MINGW', but I should have looked
> for '! te
Clemens Buchacher writes:
> On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> > I wonder what would break if we ask this question instead:
>> >
>> > We do not know if the working tree file and the indexed data
>> > match. Let's see if "git
> You had some good measurements in the coverletter, which is not going to be
> recorded in the projects history. This part however would be part of the
> commit.
> So you could move the speed improvements here (as well as the other
> reasoning) on why this is a good idea. :)
I considered that,
On Tue, Jan 26, 2016 at 01:13:16PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
> >
> >> > If you cannot trust those with write access to a repo that you are
> >> > pulling and installing from you might want to re-check wh
Hello, sorry for being MIA yesterday among all this movement...
On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 27.01.2016 08:33:
> > On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:
> >
> >>> Tag objects already have a "tag" head
On Thu, Jan 28, 2016 at 12:36 PM, Matthias Asshauer wrote:
> From: Matthias Aßhauer
>
> Use the new "git stash--helper" builtin. It should be faster than the old
> shell code and is a first step to move
> more shell code to C.
You had some good measurements in the coverletter, which is not goin
From: Matthias Aßhauer
This patch implements a new "git stash--helper" builtin plumbing
command that will be used to migrate "git-stash.sh" to C.
We start by implementing only the "--non-patch" option that will
handle the core part of the non-patch stashing.
Signed-off-by: Matthias Aßhauer
---
From: Matthias Aßhauer
Use the new "git stash--helper" builtin. It should be faster than the old shell
code and is a first step to move
more shell code to C.
Signed-off-by: Matthias Aßhauer
---
git-stash.sh | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/git-stas
Ignore -- I left an extra blank line. v3 is sent.
On Thu, Jan 28, 2016 at 2:20 PM, Andrew Wheeler wrote:
> From: Andrew Wheeler
>
> The --force--with-lease push option leads to less
> detailed status information than --force. In particular,
> the output indicates that a reference was fast-forwar
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref sta
From: Andrew Wheeler
The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.
Modify the --force-with-lease ref status logic to leverage
the --force ref sta
Moritz Neeb writes:
> the next Google Summer of Code is not too far away. I expect git to
> apply for it and hopefully have some student spots which in turn I plan
> to apply. It was recommended elsewhere and on this list as well, that it
> is beneficial to engage with the community early, that's
These are the first two Patches in an upcomming series of Patches to
convert git stash into a builtin command. This is mainly based on the
general performance of scripts running inside an interpreter (bash in
this case) running inside a POSIX emulation layer on Windows. Shell,
perl and python scrip
Duy Nguyen writes:
>> I cannot see why it cannot live in $C/common/config, which would be
>> read as the fourth alternative in your earlier enumeration. What I
>> am missing?
>
> I wasn't clear. The last paragraph is about already released git
> binaries, which does not care about $C/common/conf
Hi All!
There are two bugs in `git filter-branch`, present in the most recent
versions (d10e2cb9d0299a26f43d57dd5bdcf2b3f86a30b3), as well as in the old
ones (I couldn't find a version where it works properly).
The script:
#!/bin/sh
set -e
GIT_EXEC_PATH=/tmp/git
export GIT_EXEC_PATH
GIT=$GIT_E
On Thu, Jan 28, 2016 at 5:12 AM, Junio C Hamano wrote:
>> +WORKTREE VERSIONS AND MIGRATION
>> +---
>> +Multiple worktree is still an experimental feature and evolving. Every
>> +time the behavior is changed, the "worktree version" is stepped
>> +up. Worktree version is
On Thu, Jan 28, 2016 at 5:22 AM, Junio C Hamano wrote:
>> With this patch, since worktree v1, the repo config file (or worktree
>> config file in multi worktree context) is no longer shared. Main
>> worktree reads $C/config. Linked worktrees read $C/worktrees/xxx/config
>> and a new file, $C/work
This function returns true if git is running under an UTF-8
locale. pcre in the next patch will need this.
is_encoding_utf8() is used instead of strcmp() to catch both "utf-8"
and "utf8" suffixes.
When built with no gettext support, we peek in several env variables
to detect UTF-8. pcre library m
getaddrinfo() may return multiple addresses, not all of which
are equally performant. In some cases, a user behind a non-IPv6
capable network may get an IPv6 address which stalls connect().
Instead of waiting synchronously for a connect() to timeout, use
non-blocking connect() in parallel and take
Similar to the previous commit, we can't use kws on icase search
outside ascii range. But we can't simply pass the pattern to
regcomp/pcre like the previous commit because it may contain regex
special characters, so we need to quote the regex first.
To avoid misquote traps that could lead to undef
Similar to the "grep -F -i" case, we can't use kws on icase search
outside ascii range, so we quote the string and pass it to regcomp as
a basic regexp and let regex engine deal with case sensitivity.
The new test is put in t7812 instead of t4209-log-pickaxe because
lib-gettext.sh might cause prob
The default tables are usually built with C locale and only suitable
for LANG=C or similar. This should make case insensitive search work
correctly for all single-byte charsets.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 8 ++--
grep.h
There's another regcomp code block coming in this function. By moving
the error handling code out of this block, we don't have to add the
same error handling code in the new block.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diffcore-pickaxe.c | 16
1 file changed, 8 insertions(+),
In the previous change in this function, we add locale support for
single-byte encodings only. It looks like pcre only supports utf-* as
multibyte encodings, the others are left in the cold (which is
fine).
We need to enable PCRE_UTF8 so pcre can find character boundary
correctly. It's needed for
When we detect the pattern is just a literal string, we avoid heavy
regex engine and use fast substring search implemented in kwsset.c.
But kws uses git-ctype which is locale-independent so it does not know
how to fold case properly outside ascii range. Let regcomp or pcre
take care of this case in
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 7b2b96a..e739d20 100644
--- a/grep.c
+++ b/grep.c
@@ -403,9 +403,11 @@ static void compile_regexp(struct grep_pat *p, struct
grep_opt *opt)
p->wo
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-regex.c | 56 ++--
1 file changed, 50 insertions(+), 6 deletions(-)
diff --git a/test-regex.c b/test-regex.c
index 0dc598e..3b5641c 100644
--- a/test-regex.c
+++ b/test-regex.c
@@ -1,19 +1,63 @@
#in
The series fixes grep choosing fast path that only works correctly for
ascii. This is a resend of v4 [1] after rebase. I think v4 just went
off radar for some reason, nothing was wrong with it (or nobody told
me about it).
[1] http://thread.gmane.org/gmane.comp.version-control.git/273381/focus=276
-F means "no regex", not "case sensitive" so it should not override -i
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 5526fd7..4be0df5 100644
--- a/builtin/grep.c
+++ b/builtin/grep.
On 01/28/2016 02:18 AM, Stefan Beller wrote:
> On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb wrote:
>> Before I may introduce myself: I'm a Computer Science student in
>> Germany, coming towards the end of my Masters. I am an enthusiastic git
>> user that's why I'd like to give something back.
>
>
On 25 Jan 2016, at 02:25, Junio C Hamano wrote:
> 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 fil
Hello,
> > > Users can always go back to the original format. At least I don't
> > > expect this new format becoming the default too quickly.
>
> This is the most crucial issue here, as far as I am concerned: there are
> already tons of .zip files out there that were created by git archive, and
>
When creating default files we do not check for error codes
returned by `git_config_set` functions. This may cause the user
to end up with an inconsistent repository without any indication
for the user.
Fix this problem by dying with an error message when we are
unable to write the configuration f
When we try to unset upstream configurations we do not check
return codes for the `git_config_set` functions. As those may
indicate that we were unable to unset the respective
configuration we may exit successfully without any error message
while in fact the upstream configuration was not unset.
F
When we start picking a range of revisions we save the replay
options that are required to restore state when interrupting and
later continuing picking the revisions. However, we do not check
the return values of the `git_config_set` functions, which may
lead us to store incomplete information. As
I've finally got around to producing version two of my previous
patch to handle errors when setting configs. Back in September
I've posted a single patch to handle errors when
`install_branch_config` fails due to configuration failures [1].
Failure to write the configuration file may be caused by
The return codes for function calls that write the new URL
configuration are not being checked in `set_url`. As the function
is exposed to the user directly through `git remote set-url` we
want to inform her that we were not able to complete the request
and abort the program.
Signed-off-by: Patric
The install_branch_config function may fail to write the
configuration file due to locking. To accomodate for this
scenario, introduce a return value which may be used to check if
the function did finish correctly and adjust callers to use this
error code.
Signed-off-by: Patrick Steinhardt
---
b
When calling `git_config_set` to set 'core.precomposeunicode' we
ignore the return value of the function, which may indicate that
we were unable to write the value back to disk.
As surrounding code is already dying when an error occurs we
simply die and print an error message when we are unable to
When setting the 'core.worktree' option for a newly cloned
submodule we ignore the return value of `git_config_set_in_file`.
Instead, we want to inform the user that something has gone wrong
by printing an error message and aborting the program.
Signed-off-by: Patrick Steinhardt
---
builtin/subm
A lot of call-sites for the existing family of `git_config_set`
functions do not check for errors that may occur, e.g. the
configuration file being locked. In many cases we simply want to
die when such a situation arises.
Introduce wrappers that will cause the program to die in those
cases.
Signe
The clone command does not check for error codes returned by
`git_config_set` functions. This may cause the user to end up
with an inconsistent repository without any indication with what
went wrong.
Fix this problem by dying with an error message when we are
unable to write the configuration file
Hi Eric,
On Thu, 28 Jan 2016, Eric Sunshine wrote:
> On Wed, Jan 27, 2016 at 11:19 AM, Johannes Schindelin
> wrote:
> > Relative to v2, this fixes stupid typos that made the tests fail on
> > Linux, a stupid copy-paste error pointed out by Eric Sunshine,
> > unnecessary 'printf ""' calls pointed
Hi Andrey,
on this mailing list, it is considered impolite to top-post, and it is
also expected to reply-to-all unless there is a very good reason not to.
Currently, you are trying to abuse me as a free help desk, which I do not
appreciate.
This time I am re-Cc:ing the mailing list and reply inli
On 28 Jan 2016, at 01:40, Moritz Neeb wrote:
> As the list of available microprojects 2016 is still to be created, I
> might need your help in finding a project to work on.
As Stefan already pointed out, working on something that scratches your (Git)
itch is probably the best way to find a pro
On Wed, Jan 27, 2016 at 11:19 AM, Johannes Schindelin
wrote:
> Relative to v2, this fixes stupid typos that made the tests fail on
> Linux, a stupid copy-paste error pointed out by Eric Sunshine,
> unnecessary 'printf ""' calls pointed out by Junio Hamano, and I now
> use `test_have_prereq !MINGW`
Hi Eric,
On Thu, 28 Jan 2016, Eric Sunshine wrote:
> On Wed, Jan 27, 2016 at 11:19 AM, Johannes Schindelin
> wrote:
> > 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
> > p
Hi Moritz & Andrew,
On Thu, 28 Jan 2016, Andrew Ardill wrote:
> On 28 January 2016 at 11:40, Moritz Neeb wrote:
> > I suppose just fixing/revising this would be kind
> > of a too low hanging fruit?
>
> I am in no way qualified to speak to the majority of your post, but I
> can't imagine anyone
On Wed, Jan 27, 2016 at 11:19 AM, Johannes Schindelin
wrote:
> 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-dae
Hi Philip,
On Wed, 27 Jan 2016, Philip Oakley wrote:
> From: "Junio C Hamano"
> > Jonathan Smith writes:
> >
> > > 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.
>
Hi Robert,
[I am not going to re-Cc: the dropped email addresses; please note that it
is pretty much frowned upon on this mailing list if you do not
reply-to-all and might affect your conversation.]
On Thu, 28 Jan 2016, f...@fuz.su wrote:
> On Wed, Jan 27, 2016 at 09:31:15PM +0100, René Scharfe
86 matches
Mail list logo
