From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
This patch set replaces calls to signal() with sigaction() in all files
except
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
Replaced signal() with sigaction() in daemon.c service_loop()
Signed-off-by:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
Replaced signal() with sigaction() in daemon.c child_handler()
Signed-off-by:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
Replaced signal() with sigaction() in connect.c
Signed-off-by: Jeremiah Mahler
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
Replaced signal() with sigaction() in progress.c
Signed-off-by: Jeremiah Mahler
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
Replaced signal() with sigaction() in daemon.c run_service()
Signed-off-by:
Felipe Contreras wrote:
== git update ==
Another proposed solution is to have a new command: `git update`. This
command would be similar to `git pull --ff-only` by default, but it
could be configured to do merges instead, and when doing so in reverse.
And here it is:
Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
This patch set replaces calls
On 28/05/14 18:14, Jeremiah Mahler wrote:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability below.
Minor nit. The last sentence
On 28/05/14 19:40, Johannes Sixt wrote:
Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See Portability
Chris Packham judge.pack...@gmail.com writes:
On 28/05/14 18:14, Jeremiah Mahler wrote:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead. See
On Wed, May 28, 2014 at 10:11 AM, Chris Packham judge.pack...@gmail.com wrote:
On 28/05/14 19:40, Johannes Sixt wrote:
Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different
On Wed, May 28, 2014 at 10:19 AM, David Kastrup d...@gnu.org wrote:
Chris Packham judge.pack...@gmail.com writes:
On 28/05/14 18:14, Jeremiah Mahler wrote:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions
Philippe Vaucher wrote:
Sorry if I missed a thread where it was already decided not to include
it.
Felipe, please don't use this to start any non-constructive behavior
(rant on who is right/wrong, my patches are not accepted, etc).
I never sent those patches. I gave up on the Git project.
Erik Faye-Lund kusmab...@gmail.com writes:
On Wed, May 28, 2014 at 10:19 AM, David Kastrup d...@gnu.org wrote:
Chris Packham judge.pack...@gmail.com writes:
On 28/05/14 18:14, Jeremiah Mahler wrote:
static void clear_progress_signal(void)
{
struct itimerval v = {{0,},};
+struct
On Mon, May 26, 2014 at 1:33 PM, Tanay Abhra tanay...@gmail.com wrote:
Add an internal cache with the all variable value pairs read from the usual
config files(repo specific .git/config, user wide ~/.gitconfig and the global
s/(/ (/
/etc/gitconfig). Also, add two external functions
On Mon, May 26, 2014 at 1:33 PM, Tanay Abhra tanay...@gmail.com wrote:
Subject: config: Add new query functions to the api
This sounds as if you are adding new functions to the header file.
Saying ... to the api docs would been clearer. Better:
config: document new query functions
Add
On Tue, May 27, 2014 at 10:56 AM, Pasha Bolokhov
pasha.bolok...@gmail.com wrote:
@@ -1588,6 +1588,38 @@ void setup_standard_excludes(struct dir_struct *dir)
{
const char *path;
char *xdg_path;
+ const char *r_git, *gitdir = get_git_dir();
+ char *n_git,
On Tue, May 27, 2014 at 11:47 PM, Dale R. Worley wor...@alum.mit.edu wrote:
I've discovered a problem using Git. It's not clear to me what the
correct behavior should be, but it seems to me that Git is failing
in an undesirable way.
The problem arises when trying to handle a very large file.
Hi there Git developers,
I'm not sure if I found a bug in the command
git clone repo.git cloned_repo --depth 1
I follow these steps:
git init
echo First commit test.txt
git add -A
git commit -am First commit
echo Second commit test.txt
git commit -am Second commit
echo Third commit
On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer thomaskief...@web.de wrote:
I then clone the bare repository with --depth 1.
git clone file:///path/to/bare.git ./clone --depth 1
It always returns the last two commits. If I specify --depth 2 it returns
the last 3 commits.
If I use --depth 1
On 05/27/2014 08:27 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This suggests to me that our current structure is best modeled as two
independent reference back ends, with a third implementation of the same
reference API whose job it is to compose the first two.
On wo, 2014-05-28 at 21:16 +0700, Duy Nguyen wrote:
On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer thomaskief...@web.de wrote:
I then clone the bare repository with --depth 1.
git clone file:///path/to/bare.git ./clone --depth 1
It always returns the last two commits. If I specify
On Tue, May 27, 2014 at 5:25 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Comments from http://marc.info/?l=gitm=140079653930751w=2:
Ronnie Sahlberg wrote:
[...]
--- a/refs.c
+++ b/refs.c
@@ -2491,17 +2491,43 @@ static int repack_without_ref(const char *refname)
return
On Tue, May 27, 2014 at 5:27 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Comments from http://marc.info/?l=gitm=140079653930751w=2:
Ronnie Sahlberg wrote:
[Subject: update-ref.c: log transaction error from the update_ref]
The above description suggests that this is going to add new
On Tue, May 27, 2014 at 5:42 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Ronnie Sahlberg wrote:
--- a/refs.h
+++ b/refs.h
@@ -215,6 +215,15 @@ enum action_on_err {
};
/*
+ * Transaction functions that take an err argument will append an error
+ * string to this buffer if there
Am 27.05.2014 18:47, schrieb Dale R. Worley:
Even doing a 'git reset' does not put the repository in a state where
'git fsck' will complete:
You have to remove the offending commit also from the reflog.
The following snipped creates an offending commit, big_file is 2GB which
is too large for
On Tue, May 27, 2014 at 5:11 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Comments from http://marc.info/?l=gitm=140079653930751w=2:
Ronnie Sahlberg wrote:
--- a/cache.h
+++ b/cache.h
@@ -559,6 +559,8 @@ struct lock_file {
#define LOCK_DIE_ON_ERROR 1
#define LOCK_NODEREF 2
On Wed, May 28, 2014 at 08:07:38PM +1200, Chris Packham wrote:
On 28/05/14 18:14, Jeremiah Mahler wrote:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2)
Jeff King peff at peff.net writes:
[..]
Secondly, I do get the same warning about HEAD:
$ git clone repo.bundle repofrombundle
Cloning into 'repofrombundle'...
Receiving objects: 100% (3/3), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
but that
On Wed, May 28, 2014 at 09:40:55AM +0200, Johannes Sixt wrote:
Am 5/28/2014 8:14, schrieb Jeremiah Mahler:
From signal(2)
The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use
Ronnie Sahlberg wrote:
I reworded the commit message.
Thanks much. Looks good.
--
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
Michael Haggerty mhag...@alum.mit.edu writes:
I think for any two backends that are stacked, you would need to break
down a transaction as follows (here generalized to include not only
deletions):
packed-begin_transaction()
loose-begin_transaction()
# And this part is done
Ronnie Sahlberg wrote:
Updated the comment in refs.h
Thanks.
+++ b/refs.h
@@ -215,6 +215,31 @@ enum action_on_err {
};
/*
+ * On error, transaction functions append a message about what
+ * went wrong to the 'err' argument. The message mentions what
+ * ref was being updated (if
Duy Nguyen pclo...@gmail.com writes:
$ git fsck --full --strict
notice: HEAD points to an unborn branch (master)
Checking object directories: 100% (256/256), done.
fatal: Out of memory, malloc failed (tried to allocate 21474836481 bytes)
Back trace for this one
...
Not
David Turner dtur...@twopensource.com writes:
RFC follows:
1. On a case-insensitive server, git receive-pack ought to always reject
branches which are same-but-for-case of existing branches.
2. On a case-sensitive server, the same rule by default, with an option
to allow the old behavior.
On Wed, May 28, 2014 at 10:07 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
Updated the comment in refs.h
Thanks.
+++ b/refs.h
@@ -215,6 +215,31 @@ enum action_on_err {
};
/*
+ * On error, transaction functions append a message about what
+ * went wrong to the
Ronnie Sahlberg wrote:
Please re-review.
06df8942 is
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
--
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
Noam Postavsky npost...@users.sourceforge.net writes:
% git init
Initialized empty Git repository in /home/npostavs/tmp/scratch/.git/
% echo foo x
% git add x
% git commit -m x
[master (root-commit) 41be1f2] x
1 file changed, 1 insertion(+)
create mode 100644 x
% echo bar x
% git
David Kastrup d...@gnu.org writes:
diff --git a/progress.c b/progress.c
index 261314e..24df263 100644
--- a/progress.c
+++ b/progress.c
@@ -66,8 +66,12 @@ static void set_progress_signal(void)
static void clear_progress_signal(void)
{
struct itimerval v = {{0,},};
+ struct
On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com writes:
RFC follows:
1. On a case-insensitive server, git receive-pack ought to always reject
branches which are same-but-for-case of existing branches.
2. On a case-sensitive server, the
Thanks
Can you re-review these patches for me :
please review
67b8fce refs.c: add an err argument to repack_without_refs
738ac43 refs.c: add an err argument to delete_ref_loose
b78b0e0 refs.c: update ref_transaction_delete to check for error and
return status
e558f96 refs.c: add
Ronnie Sahlberg wrote:
Can you re-review these patches for me :
please review
67b8fce refs.c: add an err argument to repack_without_refs
738ac43 refs.c: add an err argument to delete_ref_loose
b78b0e0 refs.c: update ref_transaction_delete to check for error and
return status
e558f96
From: Duy Nguyen pclo...@gmail.com
I don't know how many commands are hit by this. If you have time and
gdb, please put a break point in die_builtin() function and send
backtraces for those that fail. You could speed up the process by
creating a smaller file and set the environment variable
From: Junio C Hamano gits...@pobox.com
You need to have enough memory (virtual is fine if you have enough
time) to do fsck. Some part of index-pack could be refactored into
a common helper function that could be called from fsck, but I think
it would be a lot of work.
How much memory is
On Wed, 28 May 2014, Dale R. Worley wrote:
From: Duy Nguyen pclo...@gmail.com
I don't know how many commands are hit by this. If you have time and
gdb, please put a break point in die_builtin() function and send
backtraces for those that fail. You could speed up the process by
creating a
Hi,
Looking at 67b8fcee:
Ronnie Sahlberg wrote:
On Tue, May 27, 2014 at 5:11 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
@@ -2208,6 +2208,7 @@ int commit_packed_refs(void)
struct packed_ref_cache *packed_ref_cache =
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/update-ref.c | 5 +++--
refs.c | 16 +++-
refs.h | 12
3 files changed, 22 insertions(+), 11 deletions(-)
Reviewed-by: Jonathan Nieder
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
[...]
@@ -3385,6 +3408,9 @@ int ref_transaction_update(struct ref_transaction
*transaction,
{
struct ref_update *update;
+ if (transaction-state != REF_TRANSACTION_OPEN)
+ return -1;
I still think this is a step
From: David Lang da...@lang.hm
Git was designed to track source code, there are warts that show up
in the implementation when you use individual files 4GB
I'd expect that if you want to deal with files over 100k, you should
assume that it doesn't all fit in memory.
Dale
--
To unsubscribe
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
sequencer.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the
W dniu 2014-05-27 19:16, Pasha Bolokhov pisze:
Add GIT_DIR to the list of excludes in setup_standard_excludes(),
while checking that GIT_DIR is not just '.git', in which case it
would be ignored by default, and that GIT_DIR is inside GIT_WORK_TREE
gives git-grep.txt and git-ls-files.txt. I
David Lang da...@lang.hm writes:
On Wed, 28 May 2014, Dale R. Worley wrote:
It seems that much of Git was coded under the assumption that any file
could always be held entirely in RAM. Who made that mistake? Are
people so out of touch with reality?
Git was designed to track source code,
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
fast-import.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
On Wed, 28 May 2014, Dale R. Worley wrote:
From: David Lang da...@lang.hm
Git was designed to track source code, there are warts that show up
in the implementation when you use individual files 4GB
I'd expect that if you want to deal with files over 100k, you should
assume that it doesn't
On Wed, 28 May 2014, Junio C Hamano wrote:
David Lang da...@lang.hm writes:
On Wed, 28 May 2014, Dale R. Worley wrote:
It seems that much of Git was coded under the assumption that any file
could always be held entirely in RAM. Who made that mistake? Are
people so out of touch with
Christian Couder chrisc...@tuxfamily.org writes:
+test_expect_success 'using where = before for a token in the middle of the
message' '
+ git config trailer.review.key Reviewed-by:
Don't you want to adjust this to have trailing SP, just like you
adjusted other ones like Fixes: in this
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
@@ -3474,11 +3474,28 @@ int update_ref(const char *action, const char
*refname,
const unsigned char *sha1, const unsigned char *oldval,
int flags, enum action_on_err onerr)
{
- struct ref_lock *lock;
-
Christian Couder chrisc...@tuxfamily.org writes:
+The trailers are recognized in the input message using the following
+rules:
+
+* only lines that contains a ':' (colon) are considered trailers,
+
+* the trailer lines must all be next to each other,
+
+* after them it's only possible to
Christian Couder chrisc...@tuxfamily.org writes:
+trailer.token.key::
+ This `key` will be used instead of token in the
+ trailer. After the last alphanumeric character, this variable
+ can contain some non alphanumeric characters, like for example
+ `'%'` (one percent sign),
Ronnie Sahlberg wrote:
--- a/fast-import.c
+++ b/fast-import.c
@@ -1735,15 +1735,22 @@ static void dump_tags(void)
{
static const char *msg = fast-import;
struct tag *t;
- struct ref_lock *lock;
char ref_name[PATH_MAX];
+ struct strbuf err = STRBUF_INIT;
+
Ronnie Sahlberg wrote:
Switch to using ref transactions in walker_fetch(). As part of the refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would fail we would end up returning from
the function without free()ing the msg
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major contributor to the
runtime. Provide two optimized versions of this function: one for
machines with SSE4.2, and one
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 35 +--
1 file changed, 9 insertions(+), 26 deletions(-)
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
On Wed, May 28, 2014 at 12:56 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
Switch to using ref transactions in walker_fetch(). As part of the
refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major contributor to the
runtime. Provide two optimized versions of this function: one for
machines with SSE4.2, and one
I just tested the previous patch on a Mac with clang and it needed
some tweaks.
Also, I should clarify that this represents a real use-case: we really
do have tens of thousands of branches on some repos. It would be nice
if people would clean up after themselves, but they don't.
(Also, it's
Done.
Thanks.
On Wed, May 28, 2014 at 12:31 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
@@ -3474,11 +3474,28 @@ int update_ref(const char *action, const char
*refname,
const unsigned char *sha1, const unsigned char *oldval,
David Turner dtur...@twopensource.com writes:
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major contributor to the
runtime. Provide two optimized versions of this
On 05/28/2014 11:04 PM, David Turner wrote:
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major contributor to the
runtime. Provide two optimized versions of this
On Wed, May 28, 2014 at 11:51 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
--- a/refs.c
+++ b/refs.c
[...]
@@ -3385,6 +3408,9 @@ int ref_transaction_update(struct ref_transaction
*transaction,
{
struct ref_update *update;
+ if (transaction-state !=
Ronnie Sahlberg wrote:
Change prune_ref to delete the ref using a ref transaction. To do this we also
need to add a new flag REF_ISPRUNING that will tell the transaction that we
do not want to delete this ref from the packed refs.
s/from the packed refs/from packed-refs, nor delete the ref's
On Wed, May 28, 2014 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
Change prune_ref to delete the ref using a ref transaction. To do this we
also
need to add a new flag REF_ISPRUNING that will tell the transaction that we
do not want to delete this ref from
David Turner dtur...@twopensource.com writes:
On Wed, 2014-05-28 at 10:14 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com writes:
RFC follows:
1. On a case-insensitive server, git receive-pack ought to always reject
branches which are same-but-for-case of existing
On Wed, May 28, 2014 at 12:47 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
--- a/fast-import.c
+++ b/fast-import.c
@@ -1735,15 +1735,22 @@ static void dump_tags(void)
{
static const char *msg = fast-import;
struct tag *t;
- struct ref_lock *lock;
On Wed, May 28, 2014 at 5:36 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, May 27, 2014 at 10:56 AM, Pasha Bolokhov
pasha.bolok...@gmail.com wrote:
@@ -1588,6 +1588,38 @@ void setup_standard_excludes(struct dir_struct *dir)
{
const char *path;
char *xdg_path;
+
Ronnie Sahlberg wrote:
On Wed, May 28, 2014 at 12:47 PM, Jonathan Nieder jrnie...@gmail.com wrote:
--- i/fast-import.c
+++ w/fast-import.c
@@ -1735,21 +1735,28 @@ static void dump_tags(void)
{
static const char *msg = fast-import;
struct tag *t;
- char
On 05/28/2014 06:58 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I think for any two backends that are stacked, you would need to break
down a transaction as follows (here generalized to include not only
deletions):
packed-begin_transaction()
The latest feature release Git v2.0.0 is now available at the
usual places.
We had to delay the final release by a week or so because we found a
few problems in earlier release candidates (request-pull had a
regression that stopped it from showing the tags/ prefix in
Please pull tags/frotz when
Junio C Hamano gits...@pobox.com writes:
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
Heh, I do not know how this slipped in, but the real release tarball
is not in git/testing/ but found at:
https://www.kernel.org/pub/software/scm/git/
--
To
On Wed, May 28, 2014 at 3:17 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
On Wed, May 28, 2014 at 12:47 PM, Jonathan Nieder jrnie...@gmail.com wrote:
--- i/fast-import.c
+++ w/fast-import.c
@@ -1735,21 +1735,28 @@ static void dump_tags(void)
{
static const
This is the last mail I sent to you, because you ignore them anyway, and
remove them from the mailing list.
I'm am cc'ing the git-fc mailing list so there's a public track record
of this, so you can't claim it didn't happen.
Junio C Hamano wrote:
* The remote-hg/bzr remote-helper interfaces
Ronnie Sahlberg wrote:
I rely on the fact that if the transaction has failed then it is safe
to call ref_transaction_commit since it is guaranteed to return an
error too.
Yes, I am saying that behavior for ref_transaction_commit is weird.
Usually when ref_transaction_commit is called I can
Move backwards from the end of the string (more efficient for
lines which do not have trailing spaces or have just a couple).
Slightly more rare occurrences of 'text \' with a backslash
in between spaces are handled correctly.
Namely, the code in 8ba87adad6 does not reset 'last_space' when
a
On Wed, 2014-05-28 at 23:44 +0200, Michael Haggerty wrote:
On 05/28/2014 11:04 PM, David Turner wrote:
In a repository with tens of thousands of refs, the command
~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
is a bit slow. check_refname_component is a major
Felipe Contreras wrote:
In mail [3] you acknowledged my wish, and you said you were going to put
stubs for v2.0, and you didn't. You also conveniently removed this mail
from the archives.
My bad. You actually did it. I missed it because the commit is named
'Revert Merge branch
In a repository with many refs, check_refname_component can be a major
contributor to the runtime of some git commands. Provide two
optimized versions of this function: one for machines with SSE4.2, and
one for machines without. One such command is
git rev-parse HEAD
Timings for one particular
--
Kedves felhasználók e-mailben;
Túllépte 23432 box set
Web Service / Admin, és akkor nem lesz probléma a küldő és
fogadhat e-maileket, amíg újra ellenőrizni. Kérjük, frissítse kattintva
linkre, és töltse ki az adatokat, hogy ellenőrizze a számla
Kérjük, kövesse az alábbi linkre, és majd
The title pretty much says it all. Lack of this feature (or presence
of this bug [depending on your perspective]) is a major PITA.
--Jonathan
--
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
Agree, but partial here means... what? just a little doc?
On Wed, May 28, 2014 at 11:53 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 2014-05-27 19:16, Pasha Bolokhov pisze:
Add GIT_DIR to the list of excludes in setup_standard_excludes(),
while checking that GIT_DIR is not just '.git',
90 matches
Mail list logo
