On Mon, Apr 13, 2015 at 8:29 AM, Koosha Khajehmoogahi koo...@posteo.de wrote:
From: Junio C Hamano gits...@pobox.com
Let's not call this *my* change. The mechanism I did write, but I think the
most important part of the change is to decide which commands in the
log family should honor the
On Thu, Apr 16, 2015 at 02:17:32AM -0400, Jeff King wrote:
So it uses a special git-specific version of exec, and doesn't touch the
PATH. Later, we did 231af83 (Teach the git command to handle some
commands internally, 2006-02-26), which says at the end:
There's one other change: the
On Wed, Apr 15, 2015 at 11:00:20AM -0400, Matthew Rothenberg wrote:
So, I guess what I'm looking for is:
- A way to prevent the **path to the running git itself** portion
of setup_path from firing, (OR)
Yeah, this behavior leaves me somewhat confused. It is obviously
dangerous (since we
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
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
+++
The test passes if one replaces the 'e' command with a 'y' command in
the 'add -p' session.
Reported-by: Tanky Woo wtq1...@gmail.com
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
t/t3701-add-interactive.sh | 22 ++
1 file changed, 22 insertions(+)
diff --git
The old description is rather clearly a wrong cut-and-paste from
t2016-checkout-patch.sh.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
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
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
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
+++
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
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
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
- 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
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.
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
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
hitting
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
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
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
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
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
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
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
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
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 turned
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
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 Praveen 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 is still accessing the file and thus it can not be
deleted (due to the implicit
Hi Junio,
On 2015-04-15 20:48, Junio C Hamano wrote:
Johannes Sixt j...@kdbg.org 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
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-term
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
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 ;-)
-
Hi kusma,
On 2015-04-15 21:43, Erik Faye-Lund wrote:
On Wed, Apr 15, 2015 at 8:29 PM, Johannes Sixt j...@kdbg.org 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
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 various
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 is still
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 virus (~
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.
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
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 gitter.spi...@gmail.com
---
t/test-lib-functions.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
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 matthieu@imag.fr
---
line-log.c | 3 ++-
1 file changed, 2
Johannes Schindelin johannes.schinde...@gmx.de 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
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 would
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 file,
Elia Pinto gitter.spi...@gmail.com 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
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, we
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
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 certain
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
Robin Moussu robin.mou...@gmail.com 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
Carlos Martín Nieto c...@elego.de 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
Hi,
On 2015-04-16 17:28, Junio C Hamano wrote:
Robin Moussu robin.mou...@gmail.com 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
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 literal in \xHEX on
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
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
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:
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
index
[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 the
From: Jeff King p...@peff.net
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
On 2015-04-16 18:31, David Miller wrote:
From: Jeff King p...@peff.net
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
Jeff King p...@peff.net 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
Is
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
karthik nayak karthik@gmail.com 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
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
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.
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 gits...@pobox.com
---
config.c | 6 +++---
1 file changed, 3 insertions(+), 3
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
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
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
Matthieu Moy matthieu@imag.fr 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
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
On Thu, Apr 16, 2015 at 5:45 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@imag.fr 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
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.
Matthieu Moy matthieu@grenoble-inp.fr writes:
Elia Pinto gitter.spi...@gmail.com 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
[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
(probably
Matthieu Moy matthieu@imag.fr 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
Lex Spoon l...@lexspoon.org writes:
From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001
From: Lex Spoon l...@lexspoon.org
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
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
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
On Tue, Apr 14, 2015 at 1:28 PM, Paul Tan pyoka...@gmail.com 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)
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
On April 16, 2015 5:55:25 PM GMT+05:30, Ramsay Jones
ram...@ramsay1.demon.co.uk 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
On Thu, Apr 16, 2015 at 7:10 PM, Karthik Nayak karthik@gmail.com wrote:
On April 16, 2015 7:05:04 PM GMT+05:30, Junio C Hamano gits...@pobox.com
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
On 15/04/15 04:47, Lex Spoon wrote:
From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001
From: Lex Spoon l...@lexspoon.org
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
On April 16, 2015 7:05:04 PM GMT+05:30, Junio C Hamano gits...@pobox.com
wrote:
karthik nayak karthik@gmail.com 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'
Signed-off-by: Stefan Beller sbel...@google.com
---
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
* 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
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 sbel...@google.com
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Junio C Hamano gits...@pobox.com
---
refs.c | 15 +--
1
Junio C Hamano gits...@pobox.com 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,
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
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 = buf;
+
Jeff King p...@peff.net 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;
-else
-
On Thu, 2015-04-16 at 10:16 -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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 gits...@pobox.com
---
config.c | 6 +++---
1 file changed, 3 insertions(+), 3
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 logic
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
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.
96 matches
Mail list logo
