On Thu, Apr 16, 2015 at 7:10 PM, Karthik Nayak wrote:
>
> On April 16, 2015 7:05:04 PM GMT+05:30, Junio C Hamano
> wrote:
>>
>>I meant just a different message. The point of -e is to see if the
>>thing exists. It is good to mention _how_ the result is reported
>>back to the user (i.e. via the
On April 16, 2015 7:05:04 PM GMT+05:30, Junio C Hamano
wrote:
>karthik nayak writes:
>
>> On 04/16/2015 02:22 AM, Junio C Hamano wrote:
>>
>>> This is a tangent, but while we are in the vicinity, we may want to
>>> rethink the help message we attach to the '-e' option. Technically
>>> the cur
On April 16, 2015 5:55:25 PM GMT+05:30, Ramsay Jones
wrote:
>
>commit 9e1f5bc0 ("sha1_file.c: support reading from a loose object of
>unknown type", 15-04-2015) added a new externally visible function
>which does not require more than file scope. This causes sparse to
>issue a warning message a
On Wed, Apr 15, 2015 at 08:29:30PM +0200, Johannes Sixt wrote:
| Windows does not have process groups. It is, therefore, the simplest
| to pretend that each process is in its own process group.
|
| [...]
|
| diff --git a/compat/mingw.h b/compat/mingw.h
| index 7b523cf..a552026 1006
The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
it.
No functional changes intended.
Signed-off-by: Stefan Beller
Reviewed-by: Michael Haggerty
Signed-off-by: Junio C Hamano
---
refs.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git
Signed-off-by: Stefan Beller
---
git-compat-util.h | 1 +
sha1_file.c | 41 -
wrapper.c | 41 +
3 files changed, 42 insertions(+), 41 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
ind
* We keep the speed on small transactions
(no close and reopen of fds in small transactions)
* No refactoring for refs included, only minimally invasive to the refs.c code
* applies on top of origin/sb/remove-fd-from-ref-lock replacing the last
commit there (I reworded the commit message of
This is another attempt on enabling large transactions
(large in terms of open file descriptors). We keep track of how many
lock files are opened by the ref_transaction_commit function.
When more than a reasonable amount of files is open, we close
the file descriptors to make sure the transaction c
On 15/04/15 04:47, Lex Spoon wrote:
From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001
From: Lex Spoon
Date: Sat, 11 Apr 2015 10:01:15 -0400
Subject: [PATCH] git-p4: Use -m when running p4 changes
This patch didn't want to apply for me, I'm not quite sure why but
possibly
Junio C Hamano wrote:
> Chris, do you remember if there was a reason why it was a bad idea
> to teach the normal rebase codepath to handle "--root"? I think we
> would have needed to allow "am" to apply a creation patch and start
> a new history on an unborn branch in order to do so, but I am no
On Thu, Apr 16, 2015 at 5:45 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> The old message did not mention the :regex:file form.
>>
>> To avoid overly long lines, split the message into two lines (in case
>> item->string is long, it will be the only part truncated in a narrow
>> terminal)
Matthieu Moy writes:
> The old message did not mention the :regex:file form.
>
> To avoid overly long lines, split the message into two lines (in case
> item->string is long, it will be the only part truncated in a narrow
> terminal).
>
> Signed-off-by: Matthieu Moy
> ---
> line-log.c | 3 ++-
>
On Tue, Apr 14, 2015 at 1:28 PM, Paul Tan wrote:
> Below is the fixed patch. I also decided to return NULL if `filename` is
> NULL because such an input usually indicated an uncaught error.
Unfortunately, this blurs the line between programmer error (passing
NULL for filename) and a user/configur
Matthieu Moy writes:
> The old message did not mention the :regex:file form.
>
> To avoid overly long lines, split the message into two lines (in case
> item->string is long, it will be the only part truncated in a narrow
> terminal).
>
> Signed-off-by: Matthieu Moy
> ---
> line-log.c | 3 ++-
>
[git-owner CC dutifully removed]
On Thu, Apr 16, 2015 at 05:48:42PM +0200, Johannes Schindelin wrote:
> Hi Peff,
>
> On 2015-04-16 17:28, Jeff King wrote:
> > On Thu, Apr 16, 2015 at 01:35:05PM +0200, Andreas Mohr wrote:
> >
> >> I strongly suspect that git's repacking implementation
> >> (proba
Matthieu Moy writes:
> Elia Pinto writes:
>
>> --- a/t/test-lib-functions.sh
>> +++ b/t/test-lib-functions.sh
>> @@ -478,7 +478,7 @@ test_external_without_stderr () {
>> test_path_is_file () {
>> if ! test -f "$1"
>> then
>> -echo "File $1 doesn't exist. $*"
>> +
I sure can. Just send me an ID I can pull and test in here (not really
into C, so this the least I can contribute).
Although, my expectations are very simple, I just expect(ed) the exact
same git-archive command to be run on submodule(s), and have an output
on a single zip|tar|whatever file.
Not
Am 13.04.2015 um 18:55 schrieb Dennis Kaarsemaker:
Reported by djanos_ in #git: git add segfaults when you manage to
confuse it with a submodule in the index that is no longer a submodule.
Here's his script to reproduce the segfault:
mkdir segfault
cd segfault
mkdir subrepo
cd subrepo
git ini
On Thu, Apr 16, 2015 at 11:39:04AM -0700, Junio C Hamano wrote:
> This is on top of the ".gitignore can start with UTF8 BOM" patch
> from Carlos.
>
> Second try; the first patch is new to clarify the logic in the
> codeflow after Carlos's patch, and the second one has been adjusted
> accordingly.
Am 16.04.2015 um 20:09 schrieb Pedro Rodrigues:
Good to know about git submodule foreach.
Simpler yet, I'm using:
zip -r ../project.zip . -x *.git*
Which essentially does the same thing I would need from git-archive
--recurse-submodule, zip everything excluding .git folders. Still
would be bet
Lex Spoon writes:
> From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001
> From: Lex Spoon
> Date: Sat, 11 Apr 2015 10:01:15 -0400
> Subject: [PATCH] git-p4: Use -m when running p4 changes
All of the above is duplicate and shouldn't be added to the message;
the recipient can p
With the recent change to ignore the UTF8 BOM at the beginning of
.gitignore files, we now have two codepaths that do such a skipping
(the other one is for reading the configuration files).
Introduce utf8_bom[] constant string and skip_utf8_bom() helper
and teach .gitignore code how to use it.
Si
Even though the previous step shifts where the "entry" begins, we
still iterate over the original buf[], which may begin with the
UTF-8 BOM we are supposed to be skipping. At the end of the first
line, the code grabs the contents of it starting at "entry", so
there is nothing wrong per-se, but the
Because the function reads one character at the time, unfortunately
we cannot use the easier skip_utf8_bom() helper, but at least we do
not have to duplicate the constant string this way.
Signed-off-by: Junio C Hamano
---
config.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
This is on top of the ".gitignore can start with UTF8 BOM" patch
from Carlos.
Second try; the first patch is new to clarify the logic in the
codeflow after Carlos's patch, and the second one has been adjusted
accordingly.
Junio C Hamano (4):
add_excludes_from_file: clarify the bom skipping logi
Signed-off-by: Junio C Hamano
---
attr.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/attr.c b/attr.c
index cd54697..7c530f4 100644
--- a/attr.c
+++ b/attr.c
@@ -12,6 +12,7 @@
#include "exec_cmd.h"
#include "attr.h"
#include "dir.h"
+#include "utf8.h"
const c
On Thu, 2015-04-16 at 10:16 -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Apr 16, 2015 at 08:39:55AM -0700, Junio C Hamano wrote:
> >
> >> > test_expect_success 'status untracked directory with --ignored' '
> >> > echo "ignored" >.gitignore &&
> >> > +sed -e "s/
Jeff King writes:
> On Thu, Apr 16, 2015 at 10:52:52AM -0700, Junio C Hamano wrote:
>
>> @@ -576,10 +576,8 @@ int add_excludes_from_file_to_list(const char *fname,
>>
>> el->filebuf = buf;
>>
>> -if (size >= 3 && !memcmp(buf, utf8_bom, 3))
>> -entry = buf + 3;
>> -els
On Thu, Apr 16, 2015 at 10:52:52AM -0700, Junio C Hamano wrote:
> @@ -576,10 +576,8 @@ int add_excludes_from_file_to_list(const char *fname,
>
> el->filebuf = buf;
>
> - if (size >= 3 && !memcmp(buf, utf8_bom, 3))
> - entry = buf + 3;
> - else
> - entry =
Good to know about git submodule foreach.
Simpler yet, I'm using:
zip -r ../project.zip . -x *.git*
Which essentially does the same thing I would need from git-archive
--recurse-submodule, zip everything excluding .git folders. Still
would be better to use git itself.
2015-04-16 18:56 GMT+01:00
On Thu, Apr 16, 2015 at 06:35:38PM +0100, Pedro Rodrigues wrote:
> I've been using git-archive as my main way of deploying to production
> servers, but today I've come across a git repo with submodules and
> found out that git archive has no option to include submodules on the
> output archive.
As
Signed-off-by: Junio C Hamano
---
attr.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/attr.c b/attr.c
index cd54697..7c530f4 100644
--- a/attr.c
+++ b/attr.c
@@ -12,6 +12,7 @@
#include "exec_cmd.h"
#include "attr.h"
#include "dir.h"
+#include "utf8.h"
const c
Because the function reads one character at the time, unfortunately
we cannot use the easier skip_utf8_bom() helper, but at least we do
not have to duplicate the constant string this way.
Signed-off-by: Junio C Hamano
---
config.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
This is on top of the ".gitignore can start with UTF8 BOM" patch
from Carlos.
Junio C Hamano (3):
utf8-bom: introduce skip_utf8_bom() helper
config: use utf8_bom[] from utf.[ch] in git_parse_source()
attr: skip UTF8 BOM at the beginning of the input file
attr.c | 9 +++--
config.c |
With the recent change to ignore the UTF8 BOM at the beginning of
.gitignore files, we now have two codepaths that do such a skipping
(the other one is for reading the configuration files).
Introduce utf8_bom[] constant string and skip_utf8_bom() helper
and teach .gitignore code how to use it.
Si
I've been using git-archive as my main way of deploying to production
servers, but today I've come across a git repo with submodules and
found out that git archive has no option to include submodules on the
output archive.
This simply makes git-archive unusable on this scenario.
--
Pedro Rodrigu
Jeff King writes:
> On Thu, Apr 16, 2015 at 08:39:55AM -0700, Junio C Hamano wrote:
>
>> > test_expect_success 'status untracked directory with --ignored' '
>> >echo "ignored" >.gitignore &&
>> > + sed -e "s/^/\xef\xbb\xbf/" .gitignore >.gitignore.new &&
>> > + mv .gitignore.new .gitignore
On 2015-04-16 18:31, David Miller wrote:
> From: Jeff King
> Date: Thu, 16 Apr 2015 12:26:21 -0400
>
>> Weird. In a nearby thread with the same problem, the first email that
>> mentions git-owner in a cc header is yours[1]. It's in reply to a
>> message that does not mention git-owner at all[2],
Hi Junio and Johanes,
It was effectively a less problem, and not a git problem.
My $LESS is '-r'. If I make "export LESS='-R' ", it is fixed.
Thanks a lot.
Cheers.
Robin.
signature.asc
Description: OpenPGP digital signature
From: Jeff King
Date: Thu, 16 Apr 2015 12:26:21 -0400
> Weird. In a nearby thread with the same problem, the first email that
> mentions git-owner in a cc header is yours[1]. It's in reply to a
> message that does not mention git-owner at all[2], except in the
> "Sender" field. Your agent header
[retaining davem in cc in case he is curious, and hopefully does not
see this as more spam :) ]
On Thu, Apr 16, 2015 at 06:11:47PM +0200, Johannes Schindelin wrote:
> On 2015-04-16 17:56, David Miller wrote:
> > Hey folks, please remove git-owner from the CC: list, that goes
> > to me and not th
Hi David,
On 2015-04-16 17:56, David Miller wrote:
> Hey folks, please remove git-owner from the CC: list, that goes
> to me and not the list :-)
I feared as much, but I cannot recall putting you on any Cc: myself. It
appeared to me as if the list added git-owner@vger as sender, at least under
On 2015-04-16 16.05, Carlos Martín Nieto wrote:
[]
May be it is easier to move this into an own function, like remove_utf8_bom() ?
> dir.c | 8 +++-
> t/t7061-wtstatus-ignore.sh | 2 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/dir.c b/dir.c
> in
Hi,
On 2015-04-16 17:39, Junio C Hamano wrote:
> Also do we need a similar change to the attribute side, or are we
> already covered and we forgot to do the same for the ignore files?
I fear so: https://github.com/git/git/blob/v2.3.5/attr.c#L359-L376
As for the config, we are safe:
https://git
Please remove git-owner from the CC: list in future replies, thank
you. :-)
--
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
Hey folks, please remove git-owner from the CC: list, that goes
to me and not the list :-)
--
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
On Thu, Apr 16, 2015 at 08:39:55AM -0700, Junio C Hamano wrote:
> > test_expect_success 'status untracked directory with --ignored' '
> > echo "ignored" >.gitignore &&
> > + sed -e "s/^/\xef\xbb\xbf/" .gitignore >.gitignore.new &&
> > + mv .gitignore.new .gitignore &&
>
> Is this "write
Hi Peff,
On 2015-04-16 17:28, Jeff King wrote:
> On Thu, Apr 16, 2015 at 01:35:05PM +0200, Andreas Mohr wrote:
>
>> I strongly suspect that git's repacking implementation
>> (probably unrelated to msysgit-specific deviations,
>> IOW, git *core* handling)
>> simply is buggy
>> in that it may keep
Hi,
On 2015-04-16 17:28, Junio C Hamano wrote:
> Robin Moussu writes:
>
>> I have a bug using the following command:
>>
>> git log --oneline --decorate --graph
>>
>> In short, the first line of the log is often truncated.
I imagine that the pager (`less`) cuts off the lines because we start
Carlos Martín Nieto writes:
> diff --git a/dir.c b/dir.c
> index 0943a81..6368247 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -581,6 +581,7 @@ int add_excludes_from_file_to_list(const char *fname,
> struct stat st;
> int fd, i, lineno = 1;
> size_t size = 0;
> + static const uns
Robin Moussu writes:
> I have a bug using the following command:
>
> git log --oneline --decorate --graph
>
> In short, the first line of the log is often truncated.
> ...
> # How to reproduce
>
> Open a small terminal windows (4*100)
>
> mkdir tmp
> cd tmp
> git init
> git co
On Thu, Apr 16, 2015 at 01:35:05PM +0200, Andreas Mohr wrote:
> I strongly suspect that git's repacking implementation
> (probably unrelated to msysgit-specific deviations,
> IOW, git *core* handling)
> simply is buggy
> in that it may keep certain file descriptors open
> at least a certain time (
On Thu, 2015-04-16 at 16:05 +0200, Carlos Martín Nieto wrote:
> Some text editors like Notepad or LibreOffice write an UTF-8 BOM in
> order to indicate that the file is Unicode text rather than whatever the
> current locale would indicate.
>
> If someone uses such an editor to edit a gitignore fil
On Thu, 2015-04-16 at 17:03 +0200, Johannes Schindelin wrote:
> Hi Carlos,
>
> On 2015-04-16 16:05, Carlos Martín Nieto wrote:
> > Some text editors like Notepad or LibreOffice write an UTF-8 BOM in
> > order to indicate that the file is Unicode text rather than whatever the
> > current locale wou
Hi Carlos,
On 2015-04-16 16:05, Carlos Martín Nieto wrote:
> Some text editors like Notepad or LibreOffice write an UTF-8 BOM in
> order to indicate that the file is Unicode text rather than whatever the
> current locale would indicate.
>
> If someone uses such an editor to edit a gitignore file,
Johannes Schindelin writes:
> On 2015-04-15 20:48, Junio C Hamano wrote:
>
>> The patch should do for now, but I suspect that it may give us a
>> better abstraction to make the "is_foreground_fd(int fd)" or even
>> "is_foreground(void)" the public API that would be implemented as
>>
>> int
Elia Pinto writes:
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -478,7 +478,7 @@ test_external_without_stderr () {
> test_path_is_file () {
> if ! test -f "$1"
> then
> - echo "File $1 doesn't exist. $*"
> + echo "File $1 doesn't exist.
The old message did not mention the :regex:file form.
To avoid overly long lines, split the message into two lines (in case
item->string is long, it will be the only part truncated in a narrow
terminal).
Signed-off-by: Matthieu Moy
---
line-log.c | 3 ++-
1 file changed, 2 insertions(+), 1 dele
The second argument to test_path_is_file and test_path_is_dir
must be $2 and not $*, which instead would repeat the file
name in the error message.
Signed-off-by: Elia Pinto
---
t/test-lib-functions.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib-functions.s
Some text editors like Notepad or LibreOffice write an UTF-8 BOM in
order to indicate that the file is Unicode text rather than whatever the
current locale would indicate.
If someone uses such an editor to edit a gitignore file, we are left
with those three bytes at the beginning of the file. If w
karthik nayak writes:
> On 04/16/2015 02:22 AM, Junio C Hamano wrote:
>
>> This is a tangent, but while we are in the vicinity, we may want to
>> rethink the help message we attach to the '-e' option. Technically
>> the current message is _not_ wrong per-se, but it misses the point.
>> The prima
Hi Andreas,
On 2015-04-16 14:35, Andreas Mohr wrote:
> On Thu, Apr 16, 2015 at 01:48:46PM +0200, Andreas Mohr wrote:
>> OK, at this point in time it's my turn to actually verify
>> that indeed it's NOT the virus scanner:
>> - generate rebase-heavy activity
>> - update
>> - hit issue
>> - unload vi
Hi Torsten,
On 2015-04-15 21:58, Torsten Bögershausen wrote:
> Yes, I try to be up-to-date with Git for Windows, but missed to follow
> this very patch.
> Do you plan to send it to git.git ?
I did plan to send it to this mailing list (together with the other 23 branches
we accumulated in all th
Hi Junio,
On 2015-04-15 20:48, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Windows does not have process groups. It is, therefore, the simplest
>> to pretend that each process is in its own process group.
>>
>> While here, move the getppid() stub from its old location (between
>> two sync
Hi kusma,
On 2015-04-15 21:43, Erik Faye-Lund wrote:
> On Wed, Apr 15, 2015 at 8:29 PM, Johannes Sixt wrote:
>> Windows does not have process groups. It is, therefore, the simplest
>> to pretend that each process is in its own process group.
>
> Windows does have some concept of process groups,
On Thu, Apr 16, 2015 at 01:48:46PM +0200, Andreas Mohr wrote:
> OK, at this point in time it's my turn to actually verify
> that indeed it's NOT the virus scanner:
> - generate rebase-heavy activity
> - update
> - hit issue
> - unload virus (~ scanner?? I'm unsure on exact terminology to be used ;-
commit 9e1f5bc0 ("sha1_file.c: support reading from a loose object of
unknown type", 15-04-2015) added a new externally visible function
which does not require more than file scope. This causes sparse to
issue a warning message about this symbol. In order to suppress the
warning, add the static qu
On Thu, Apr 16, 2015 at 01:42:35PM +0200, Andreas Mohr wrote:
> Hi,
>
> On Thu, Apr 16, 2015 at 01:31:02PM +0200, Johannes Schindelin wrote:
> > Hi,
> >
> > On 2015-04-16 13:10, Thomas Braun wrote:
> > > I've never had this issue. The error message from unlinking the file
> > > means that someone
Hi,
On Thu, Apr 16, 2015 at 01:31:02PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On 2015-04-16 13:10, Thomas Braun wrote:
> > I've never had this issue. The error message from unlinking the file
> > means that someone is still accessing the file and thus it can not be
> > deleted (due to the im
Hi,
sorry, I had sent the prior mail prematurely (hit wrong key)
and have been busy working on the resubmission...
On Thu, Apr 16, 2015 at 01:10:36PM +0200, Thomas Braun wrote:
> Am 16.04.2015 um 12:03 schrieb Andreas Mohr:
> > Hi all,
> >
> > over the years I've had the same phenomenon with var
Hi,
On 2015-04-16 13:10, Thomas Braun wrote:
> Am 16.04.2015 um 12:03 schrieb Andreas Mohr:
>>
>> over the years I've had the same phenomenon with various versions of msysgit
>> (now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently
>> confident of it being a long-standing, longer-t
Am 16.04.2015 um 12:03 schrieb Andreas Mohr:
> Hi all,
>
> over the years I've had the same phenomenon with various versions of msysgit
> (now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently
> confident of it being a long-standing, longer-term issue and thus I'm
> reporting it now
I have a bug using the following command:
git log --oneline --decorate --graph
In short, the first line of the log is often truncated.
If the terminal is too small to display all the text (~100 columns, and too
much text to fit on the high of screen, in this example less than 4
lines), I
ac
Hi all,
over the years I've had the same phenomenon with various versions of msysgit
(now at 1.9.5.msysgit.0, on Windows 7 64bit), so I'm now sufficiently
confident of it being a long-standing, longer-term issue and thus I'm
reporting it now.
Since I'm doing development in a sufficiently rebase-h
On Thu, Apr 16, 2015 at 01:37:54AM -0700, Yi EungJun wrote:
> > - Written policy: https://git-scm.com/trademark
>
> My browser shows an "Untrusted Connection" page when click the link.
>
> Does git-scm have no TLS certificate?
Hmm, you're right. It has a *.herokuapp.com cert. That's fine for
h
Trevor Saunders venit, vidit, dixit 15.04.2015 20:59:
> On Wed, Apr 15, 2015 at 07:46:15PM +0200, Johannes Schindelin wrote:
>> Hi Trevor,
>>
>> On 2015-04-15 17:33, Trevor Saunders wrote:
>>> On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:
On 2015-04-15 16:18, Pirate
On Thu, Apr 16, 2015 at 04:47:34AM -0400, Jeff King wrote:
> Here's a re-roll incorporating feedback from the list. Thanks everybody
> for your comments. Last time the final number was ~8.5s, which was
> disappointingly slower than v2.0.0. In this iteration, my final numbers
> are:
>
> real
In t1430, we check whether deleting the branch "../../foo"
will delete ".git/foo". However, this is not that
interesting a test; the precious file ".git/foo" does not
look like a ref, so even if we did not notice the "escape"
from the "refs/" hierarchy, we would fail for that reason
(i.e., if you t
Prior to d0f810f (refs.c: allow listing and deleting badly
named refs, 2014-09-03), read_packed_refs would barf on any
malformed refnames by virtue of calling create_ref_entry
with the "check" parameter set to 1. That commit loosened
our reading so that we call check_refname_format ourselves
and ju
We spend a lot of time in strbuf_getwholeline in a tight
loop reading characters from a stdio handle into a buffer.
The libc getdelim() function can do this for us with less
overhead. It's in POSIX.1-2008, and was a GNU extension
before that. Therefore we can't rely on it, but can fall
back to the
As with the recent speedup to strbuf_addch, we can avoid
calling strbuf_grow() in a tight loop of single-character
adds by instead checking strbuf_avail.
Note that we would instead call strbuf_addch directly here,
but it does more work than necessary: it will NUL-terminate
the result for each char
We mark strbuf_addch as inline, because we expect it may be
called from a tight loop. However, the first thing it does
is call the non-inline strbuf_grow(), which can handle
arbitrary-sized growth. Since we know that we only need a
single character, we can use the inline strbuf_avail() to
quickly c
We read config files character-by-character from a stdio
handle using fgetc(). This incurs significant locking
overhead, even though we know that only one thread can
possibly access the handle. We can speed this up by taking
the lock ourselves, and then using getc_unlocked to read
each character.
strbuf_getwholeline calls getc in a tight loop. On modern
libc implementations, the stdio code locks the handle for
every operation, which means we are paying a significant
overhead. We can get around this by locking the handle for
the whole loop and using the unlocked variant.
Running "git rev-p
POSIX.1-2001 specifies some functions for optimizing the
locking out of tight getc() loops. Not all systems are
POSIX, though, and even not all POSIX systems are required
to implement these functions. We can check for the
feature-test macro to see if they are available, and if not,
provide a noop i
strbuf_getwholeline calls fgetc in a tight loop. Using the
getc form, which can be implemented as a macro, should be
faster (and we do not care about it evaluating our argument
twice, as we just have a plain variable).
On my glibc system, running "git rev-parse
refs/heads/does-not-exist" on a file
On Sat, Apr 04, 2015 at 09:06:11PM -0400, Jeff King wrote:
> As I've mentioned before, I have some repositories with rather large
> numbers of refs. The worst one has ~13 million refs, for a 1.6GB
> packed-refs file. So I was saddened by this:
>
> $ time git.v2.0.0 rev-parse refs/heads/foo >/de
> - Written policy: https://git-scm.com/trademark
My browser shows an "Untrusted Connection" page when click the link.
Does git-scm have no TLS certificate?
--
View this message in context:
http://git.661346.n2.nabble.com/Git-SFC-Status-Update-tp7628669p7628850.html
Sent from the git mailing
On 04/16/2015 02:22 AM, Junio C Hamano wrote:
Junio C Hamano writes:
Karthik Nayak writes:
...
- if (argc != 3 && argc != 2)
+ if (argc < 2 || argc > 4)
usage_with_options(cat_file_usage, options);
Hmm, why this change?
By allowing 4 args blindly like this, y
Change since v2: simplify the code (for consistancy, I also changed
the code I copy/pasted from in a separate patch).
Still out of Git time budget though :-(.
Matthieu Moy (5):
t3701-add-interactive: simplify code
add -p: demonstrate failure when running 'edit' after a split
t3904-stash-pat
Signed-off-by: Matthieu Moy
---
t/t3904-stash-patch.sh | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 9a59683..0f8f47f 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -3,7 +3,13 @@
The test passes if one replaces the 'e' command with a 'y' command in
the 'add -p' session.
Reported-by: Tanky Woo
Signed-off-by: Matthieu Moy
---
t/t3701-add-interactive.sh | 22 ++
1 file changed, 22 insertions(+)
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-inte
The old description is rather clearly a wrong cut-and-paste from
t2016-checkout-patch.sh.
Signed-off-by: Matthieu Moy
---
t/t3904-stash-patch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 70655c1..9a59683 100755
--- a
Signed-off-by: Matthieu Moy
---
t/t3701-add-interactive.sh | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 24ddd8a..b63b9d4 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -326,10 +32
Signed-off-by: Matthieu Moy
---
t/t3904-stash-patch.sh | 23 +++
1 file changed, 23 insertions(+)
diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 0f8f47f..38e7300 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -81,4 +81,27 @@ test_expec
95 matches
Mail list logo
