Re: [PATCH] gc: remove redundant check for gc_auto_threshold

On Wed, Oct 10, 2018 at 4:38 PM Junio C Hamano wrote: > > Brandon Casey writes: > > > ... Again, I don't feel strongly about it, but I'm not > > sure this change actually improves the code. > > Yeah, in the context of the current caller, this is a safe change &g

Re: [PATCH] gc: remove redundant check for gc_auto_threshold

On Wed, Oct 10, 2018 at 12:32 PM Ævar Arnfjörð Bjarmason wrote: > > Checking gc_auto_threshold in too_many_loose_objects() was added in > 17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.", > 2007-09-17) when need_to_gc() itself was also reliant on > gc_auto_pack_limit before its

Re: Shawn Pearce has died

On Mon, Jan 29, 2018 at 2:55 PM, Christian Couder wrote: > On Mon, Jan 29, 2018 at 6:21 PM, Jeff King wrote: >> On Mon, Jan 29, 2018 at 10:33:08AM +0100, Johannes Schindelin wrote: >> >>> I found these sad news in my timeline today: >>> >>>

[PATCH 2/3] parse-options: write blank line to correct output stream

When commit 54e6dc7 added translation support to parse-options, an fprintf was mistakenly replaced by a call to putchar(). Let's use fputc instead. Fixes t0040.11, t0040.12, t0040.33, and t1502.8. Signed-off-by: Brandon Casey <draf...@gmail.com> --- parse-options.c | 2

[PATCH 3/3] parse-options: only insert newline in help text if needed

trailing blank lines instead of one. Let's defer emitting the blank line between the usage text and the options text until it is clear that the options section will not be empty. Fixes t1502.5, t1502.6. Signed-off-by: Brandon Casey <draf...@gmail.com> --- parse-options.c

[PATCH 1/3] t0040,t1502: Demonstrate parse_options bugs

blank lines within the usage string to stdout instead of stderr. Update t/helper/test-parse-options.c to have a description body in the usage string to exercise this second bug and mark tests as failing in t0040. Add tests to t1502 to demonstrate both of these problems. Signed-off-by: Brandon Casey

[PATCH 1/4] t1502: demonstrate rev-parse --parseopt option mis-parsing

nd line. The only side-effect is misalignment in the help text. Signed-off-by: Brandon Casey <draf...@gmail.com> --- t/t1502-rev-parse-parseopt.sh | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/t/t1502-rev-parse-parseopt.sh b/t/t1502-rev-parse-parseopt.sh i

[PATCH 2/4] rev-parse parseopt: do not search help text for flag chars

of this one: set -- --exclame this does something -- Mark t1502.4 and t1502.5 as fixed. Signed-off-by: Brandon Casey <draf...@gmail.com> --- builtin/rev-parse.c | 6 -- t/t1502-rev-parse-parseopt.sh | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/b

[PATCH 3/4] rev-parse parseopt: interpret any whitespace as start of help text

owing set expression when --frotz is used: set -- --frotz -- instead of this: set -- --frotz enable -- Mark t1502.2 as fixed. Signed-off-by: Brandon Casey <draf...@gmail.com> --- builtin/rev-parse.c | 12 ++-- t/t1502-rev-parse-parseopt.sh | 2 +- 2 files ch

[PATCH 4/4] git-rebase: don't ignore unexpected command line arguments

unexpected arguments. Let's not. Signed-off-by: Brandon Casey <draf...@gmail.com> --- git-rebase.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git-rebase.sh b/git-rebase.sh index ad8415e..6344e8d 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -350,6 +350,9 @@ do

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Thu, Aug 24, 2017 at 9:52 AM, Junio C Hamano <gits...@pobox.com> wrote: > Brandon Casey <draf...@gmail.com> writes: > >> Ah, you probably meant something like this: >> >>const char strbuf_slopbuf = '\0'; >> >> which gcc will apparently

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Wed, Aug 23, 2017 at 3:24 PM, Junio C Hamano <gits...@pobox.com> wrote: > Brandon Casey <draf...@gmail.com> writes: > >> On Wed, Aug 23, 2017 at 2:04 PM, Junio C Hamano <gits...@pobox.com> wrote: >>> Brandon Casey <draf...@gmail.com> writes:

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Wed, Aug 23, 2017 at 2:54 PM, Brandon Casey <draf...@gmail.com> wrote: > On Wed, Aug 23, 2017 at 2:20 PM, Brandon Casey <draf...@gmail.com> wrote: >> On Wed, Aug 23, 2017 at 2:04 PM, Junio C Hamano <gits...@pobox.com> wrote: >>> Brandon Casey <draf...@gmai

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Wed, Aug 23, 2017 at 2:20 PM, Brandon Casey <draf...@gmail.com> wrote: > On Wed, Aug 23, 2017 at 2:04 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Brandon Casey <draf...@gmail.com> writes: >> >>> So is there any reason why didn't do something

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Wed, Aug 23, 2017 at 2:04 PM, Junio C Hamano <gits...@pobox.com> wrote: > Brandon Casey <draf...@gmail.com> writes: > >> So is there any reason why didn't do something like the following in >> the first place? > > My guess is that we didn't bother; if we

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Mon, Aug 21, 2017 at 10:43 AM, Martin Ågren wrote: > strbuf_setlen(., 0) writes '\0' to sb.buf[0], where buf is either > allocated and unique to sb, or the global slopbuf. The slopbuf is meant > to provide a guarantee that buf is not NULL and that a freshly >

Re: requesting permission to use some Git for Windows code

to > specific parts, using the `-L ,` option? > >> ctype.c > > $ git shortlog -nse ctype.c > 5 Junio C Hamano <gits...@pobox.com> > 4 René Scharfe <l@web.de> > 2 Nguyễn Thái Ngọc Duy <pclo...@gmail.com> > 1 Ben Walton &l

Re: [PATCH] gnome-keyring: Don't hard-code pkg-config executable

On Thu, Jun 16, 2016 at 2:50 AM, Jeff King wrote: > On Tue, Jun 14, 2016 at 01:27:05PM +0200, Heiko Becker wrote: > >> Helpful if your pkg-config executable has a prefix based on the >> architecture, for example. >> >> Signed-off-by: Heiko Becker > > Sounds

Re: [PATCH 1/2] git-send-email.perl: support no- prefix with older GetOptions

On Sun, Feb 15, 2015 at 1:51 AM, Kyle J. McKay mack...@gmail.com wrote: On Feb 14, 2015, at 22:32, Brandon Casey wrote: On Fri, Feb 13, 2015 at 12:19 PM, Junio C Hamano gits...@pobox.com wrote: From: Kyle J. McKay mack...@gmail.com Only Perl version 5.8.0 or later is required

Re: [PATCH 0/2] Getopt::Long workaround in send-email

[apparently it is impossible to send a plain text email using Google Inbox, maybe people on this list know someone to talk to about that? Sorry for the dup for those on cc] On Fri, Feb 13, 2015 at 12:19 PM, Junio C Hamano gits...@pobox.com wrote: The first one is a replay of Kyle's workaround

Re: [PATCH 1/2] git-send-email.perl: support no- prefix with older GetOptions

On Fri, Feb 13, 2015 at 12:19 PM, Junio C Hamano gits...@pobox.com wrote: From: Kyle J. McKay mack...@gmail.com Only Perl version 5.8.0 or later is required, but that comes with an older Getopt::Long (2.32) that does not support the 'no-' prefix. Support for that was added in Getopt::Long

Re: [PATCH 1/2] sequencer.c: check for lock failure and bail early in fast_forward_to

On Tue, Apr 15, 2014 at 4:46 PM, Ronnie Sahlberg sahlb...@google.com wrote: snip well-worded commit message Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- sequencer.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/sequencer.c b/sequencer.c index bde5f04..6aa3b50 100644

Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too

On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com The setting of denyDeleteCurrent applies to both bare and non-bare repositories. Correct the description on this point, and expand

Re: [PATCH v2 00/16] Make Gnome Credential helper more Gnome-y and support ancient distros

On 10/15/2013 3:40 PM, Junio C Hamano wrote: This seems to post-date what Jonathan has kept in his 'pu'; is this the latest (I have a huge backlog to wade through, so I'd rather skip it if another reroll is coming and move on to other topics). Thanks. This is the latest. I didn't have

[PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too

From: Brandon Casey draf...@gmail.com The setting of denyDeleteCurrent applies to both bare and non-bare repositories. Correct the description on this point, and expand it to provide some background justification for the current behavior and describe the full suite of settings. Signed-off

Re: return of the maintainer

For some reason, I have the theme for Star Wars in my head. :) On Mon, Oct 14, 2013 at 10:37 AM, Junio C Hamano gits...@pobox.com wrote: I am physically back to work, but I'll have to coordinate the hand-off of topic branches updated during my absence with Jonathan before resuming to update my

Re: [PATCH 07/15] contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before accessing

Thanks. On Sun, Sep 22, 2013 at 10:43 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Brandon Casey wrote: Ensure buffer length is non-zero before attempting to access the last element. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git

Re: [PATCH 00/15] Make Gnome Credential helper more Gnome-y and support ancient distros

On Mon, Sep 23, 2013 at 3:20 AM, John Szakmeister j...@szakmeister.net wrote: On Sun, Sep 22, 2013 at 10:07:56PM -0700, Brandon Casey wrote: A few cleanups, followed by improved usage of the glib library (no need to reinvent the wheel when glib provides the necessary functionality

[PATCH v2 00/16] Make Gnome Credential helper more Gnome-y and support ancient distros

From: Brandon Casey draf...@gmail.com Mostly unchanged. Inserts a patch to fix the style issues for block statements. i.e. use if () instead of if() A couple early patches were reordered to improve logical flow. Updated the comment in the last patch to hopefully improve clarity wrt RHEL 4.X

[PATCH v2 02/16] contrib/git-credential-gnome-keyring.c: remove unused die() function

From: Brandon Casey draf...@gmail.com Signed-off-by: Brandon Casey draf...@gmail.com --- .../credential/gnome-keyring/git-credential-gnome-keyring.c| 10 -- 1 file changed, 10 deletions(-) diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c b/contrib

[PATCH v2 10/16] contrib/git-credential-gnome-keyring.c: use secure memory functions for passwds

From: Brandon Casey draf...@gmail.com gnome-keyring provides functions for allocating non-pageable memory (if possible) intended to be used for storing passwords. Let's use them. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c| 21

[PATCH v2 03/16] contrib/git-credential-gnome-keyring.c: *style* use if () not if() etc.

From: Brandon Casey draf...@gmail.com Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c

[PATCH v2 15/16] contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring

From: Brandon Casey draf...@gmail.com The gnome-keyring lib distributed with RHEL 5.X is ancient and does not provide a few of the functions/defines that more recent versions do, but mostly the API is the same. Let's provide the missing bits via macro definitions and function implementation

[PATCH v2 06/16] contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not ssize_t

From: Brandon Casey draf...@gmail.com Also, initialization is not necessary since it is assigned before it is used. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v2 14/16] contrib/git-credential-gnome-keyring.c: report failure to store password

From: Brandon Casey draf...@gmail.com Produce an error message when we fail to store a password to the keyring. Signed-off-by: Brandon Casey draf...@gmail.com --- Difference from v1: Additionally interpret GNOME_KEYRING_RESULT_CANCELLED as a successful exit status, since that means

[PATCH v2 07/16] contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before accessing

From: Brandon Casey draf...@gmail.com Ensure buffer length is non-zero before attempting to access the last element. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v2 12/16] contrib/git-credential-gnome-keyring.c: use glib memory allocation functions

From: Brandon Casey draf...@gmail.com Rather than roll our own, let's use the memory allocation/free routines provided by glib. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 48 -- 1 file changed, 16 insertions(+), 32

[PATCH v2 11/16] contrib/git-credential-gnome-keyring.c: use secure memory for reading passwords

From: Brandon Casey draf...@gmail.com gnome-keyring provides functions to allocate non-pageable memory (if possible). Let's use them to allocate memory that may be used to hold secure data read from the keyring. Signed-off-by: Brandon Casey draf...@gmail.com --- .../credential/gnome-keyring

[PATCH v2 16/16] contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring

From: Brandon Casey draf...@gmail.com The gnome-keyring lib (0.4) distributed with RHEL 4.X is really ancient and does not provide most of the synchronous functions that even ancient releases do. Thankfully, we're only using one function that is missing. Let's emulate

[PATCH v2 13/16] contrib/git-credential-gnome-keyring.c: use glib messaging functions

From: Brandon Casey draf...@gmail.com Rather than roll our own, let's use the messaging functions provided by glib. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 33 +++--- 1 file changed, 4 insertions(+), 29 deletions

[PATCH v2 08/16] contrib/git-credential-gnome-keyring.c: set Gnome application name

From: Brandon Casey draf...@gmail.com Since this is a Gnome application, let's set the application name to something reasonable. This will be displayed in Gnome dialog boxes e.g. the one that prompts for the user's keyring password. We add an include statement for glib.h and add the glib-2.0

[PATCH v2 01/16] contrib/git-credential-gnome-keyring.c: remove unnecessary pre-declarations

From: Brandon Casey draf...@gmail.com These are all defined before they are used, so it is not necessary to pre-declare them. Remove the pre-declarations. Signed-off-by: Brandon Casey draf...@gmail.com --- .../credential/gnome-keyring/git-credential-gnome-keyring.c | 13 - 1 file

[PATCH v2 09/16] contrib/git-credential-gnome-keyring.c: use gnome helpers in keyring_object()

From: Brandon Casey draf...@gmail.com Rather than carefully allocating memory for sprintf() to write into, let's make use of the glib helper function g_strdup_printf(), which makes things a lot easier and less error-prone. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git

[PATCH v2 05/16] contrib/git-credential-gnome-keyring.c: exit non-zero when called incorrectly

From: Brandon Casey draf...@gmail.com If the correct arguments were not specified, this program should exit non-zero. Let's do so. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 04/16] contrib/git-credential-gnome-keyring.c: add static where applicable

From: Brandon Casey draf...@gmail.com Mark global variable and functions as static. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/contrib/credential

[PATCH 04/15] contrib/git-credential-gnome-keyring.c: exit non-zero when called incorrectly

If the correct arguments were not specified, this program should exit non-zero. Let's do so. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/credential

[PATCH 06/15] contrib/git-credential-gnome-keyring.c: strlen() returns size_t, not ssize_t

Also, initialization is not necessary since it is assigned before it is used. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/credential/gnome-keyring

[PATCH 00/15] Make Gnome Credential helper more Gnome-y and support ancient distros

A few cleanups, followed by improved usage of the glib library (no need to reinvent the wheel when glib provides the necessary functionality), and then the addition of support for RHEL 4.x and 5.x. Brandon Casey (15): contrib/git-credential-gnome-keyring.c: remove unnecessary pre

[PATCH 01/15] contrib/git-credential-gnome-keyring.c: remove unnecessary pre-declarations

These are all defined before they are used, so it is not necessary to pre-declare them. Remove the pre-declarations. Signed-off-by: Brandon Casey draf...@gmail.com --- .../credential/gnome-keyring/git-credential-gnome-keyring.c | 13 - 1 file changed, 13 deletions(-) diff --git

[PATCH 10/15] contrib/git-credential-gnome-keyring.c: use secure memory for reading passwords

gnome-keyring provides functions to allocate non-pageable memory (if possible). Let's use them to allocate memory that may be used to hold secure data read from the keyring. Signed-off-by: Brandon Casey draf...@gmail.com --- .../credential/gnome-keyring/git-credential-gnome-keyring.c | 12

[PATCH 08/15] contrib/git-credential-gnome-keyring.c: use gnome helpers in keyring_object()

Rather than carefully allocating memory for sprintf() to write into, let's make use of the glib helper function g_strdup_printf(), which makes things a lot easier and less error-prone. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c

[PATCH 11/15] contrib/git-credential-gnome-keyring.c: use glib memory allocation functions

Rather than roll our own, let's use the memory allocation/free routines provided by glib. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 48 -- 1 file changed, 16 insertions(+), 32 deletions(-) diff --git a/contrib

[PATCH 13/15] contrib/git-credential-gnome-keyring.c: report failure to store password

Produce an error message when we fail to store a password to the keyring. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/contrib/credential/gnome

[PATCH 05/15] contrib/git-credential-gnome-keyring.c: set Gnome application name

arguments, but both of these are really noops since glib is already a dependency of gnome-keyring. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/Makefile | 4 ++-- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 3 +++ 2 files

[PATCH 02/15] contrib/git-credential-gnome-keyring.c: remove unused die() function

Signed-off-by: Brandon Casey draf...@gmail.com --- .../credential/gnome-keyring/git-credential-gnome-keyring.c| 10 -- 1 file changed, 10 deletions(-) diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c b/contrib/credential/gnome-keyring/git-credential-gnome

[PATCH 12/15] contrib/git-credential-gnome-keyring.c: use glib messaging functions

Rather than roll our own, let's use the messaging functions provided by glib. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 33 +++--- 1 file changed, 4 insertions(+), 29 deletions(-) diff --git a/contrib/credential/gnome

[PATCH 14/15] contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring

The gnome-keyring lib distributed with RHEL 5.X is ancient and does not provide a few of the functions/defines that more recent versions do, but mostly the API is the same. Let's provide the missing bits via macro definitions and function implementation. Signed-off-by: Brandon Casey draf

[PATCH 07/15] contrib/git-credential-gnome-keyring.c: ensure buffer is non-empty before accessing

Ensure buffer length is non-zero before attempting to access the last element. Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/credential/gnome-keyring

[PATCH 15/15] contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring

function and then triggering the event loop processing until our callback is called. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 39 ++ 1 file changed, 39 insertions(+) diff --git a/contrib/credential/gnome-keyring/git

[PATCH 09/15] contrib/git-credential-gnome-keyring.c: use secure memory functions for passwds

gnome-keyring provides functions for allocating non-pageable memory (if possible) intended to be used for storing passwords. Let's use them. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c| 21 ++--- 1 file changed, 6

[PATCH 03/15] contrib/git-credential-gnome-keyring.c: add static where applicable

Mark global variable and functions as static. Signed-off-by: Brandon Casey draf...@gmail.com --- .../gnome-keyring/git-credential-gnome-keyring.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/contrib/credential/gnome-keyring/git-credential-gnome

[PATCH 2/3] t9902-completion.sh: old Bash still does not support array+=('') notation

From: Brandon Casey draf...@gmail.com Old Bash (3.0) which is distributed with RHEL 4.X and other ancient platforms that are still in wide use, does not understand the array+=() notation. Let's use an explicit assignment to the new array element which works everywhere, like: array[${#array

[PATCH 1/3] git-completion.bash: use correct Bash/Zsh array length syntax

From: Brandon Casey draf...@gmail.com The syntax for retrieving the number of elements in an array is: ${#name[@]} Signed-off-by: Brandon Casey draf...@gmail.com --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion

[PATCH 3/3] Revert bash prompt: avoid command substitution when finalizing gitstring

From: Brandon Casey draf...@gmail.com This reverts commit 69a8141a5d81925b7e08cb228535e9ea4a7a02e3. Old Bash (3.0) which is distributed with RHEL 4.X and other ancient platforms that are still in wide use, does not have a printf that supports -v. Let's revert this patch and go back to using

Re: [PATCH 3/3] Revert bash prompt: avoid command substitution when finalizing gitstring

On Wed, Aug 21, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com This reverts commit 69a8141a5d81925b7e08cb228535e9ea4a7a02e3. Old Bash (3.0) which is distributed with RHEL 4.X and other ancient platforms

Re: [PATCH 3/3] Revert bash prompt: avoid command substitution when finalizing gitstring

On Wed, Aug 21, 2013 at 5:22 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: On Wed, Aug 21, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote: # on load... printf -v __git_printf_supports_v -- %s yes /dev/null 21

[PATCH] contrib/git-prompt.sh: handle missing 'printf -v' more gracefully

From: Brandon Casey draf...@gmail.com Old Bash (3.0) which is distributed with RHEL 4.X and other ancient platforms that are still in wide use, do not have a printf that supports -v. Neither does Zsh (which is already handled in the code). As suggested by Junio, let's test whether printf

[PATCH] contrib/git-prompt.sh: handle missing 'printf -v' more gracefully

From: Brandon Casey draf...@gmail.com Old Bash (3.0) which is distributed with RHEL 4.X and other ancient platforms that are still in wide use, do not have a printf that supports -v. Neither does Zsh (which is already handled in the code). As suggested by Junio, let's test whether printf

Re: [regression] Re: git-cat-file --batch reversion; cannot query filenames with spaces

On Fri, Aug 2, 2013 at 8:27 AM, Joey Hess j...@kitenet.net wrote: Jeff King wrote: By the way, Joey, I am not sure how safe git cat-file --batch-check is for arbitrary filenames. In particular, I don't know how it would react to a filename with an embedded newline (and I do not think it will

Re: [PATCH v3] sha1_file: introduce close_one_pack() to close packs on fd pressure

On Fri, Aug 2, 2013 at 9:26 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: +/* + * The LRU pack is the one with the oldest MRU window, preferring packs + * with no used windows, or the oldest mtime if it has no windows allocated. + */ +static void

Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure

On Thu, Aug 1, 2013 at 10:12 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey bca...@nvidia.com writes: If the refs are loose, then upload-pack will read each ref from the pack (allocating one or more mmap windows) so it can peel tags and advertise the underlying object. If the refs

Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure

On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: I've been looking closer at uses of p-windows everywhere, and it seems that we always open_packed_git() before we try to create new windows. There doesn't seem to be any reason

Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure

On Thu, Aug 1, 2013 at 12:16 PM, Brandon Casey draf...@gmail.com wrote: On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: I've been looking closer at uses of p-windows everywhere, and it seems that we always open_packed_git

Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure

On Thu, Aug 1, 2013 at 1:02 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote: That makes me feel somewhat uneasy. Yes, you can open/mmap/close and hold onto the contents of a file still

[PATCH v3] sha1_file: introduce close_one_pack() to close packs on fd pressure

* pack with the least-recently-used windows Signed-off-by: Brandon Casey draf...@gmail.com --- Here's the version that leaves the mmap windows open after closing the pack file descriptor. -Brandon sha1_file.c | 79 - 1 file changed, 78

[PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure

From: Brandon Casey draf...@gmail.com When the number of open packs exceeds pack_max_fds, unuse_one_window() is called repeatedly to attempt to release the least-recently-used pack windows, which, as a side-effect, will also close a pack file after closing its last open window. If a pack file

[PATCH 2/2] Don't close pack fd when free'ing pack windows

From: Brandon Casey draf...@gmail.com Now that close_one_pack() has been introduced to handle file descriptor pressure, it is not strictly necessary to close the pack file descriptor in unuse_one_window() when we're under memory pressure. Jeff King provided a justification for leaving the pack

Re: [PATCH 2/2] Don't close pack fd when free'ing pack windows

On Wed, Jul 31, 2013 at 2:08 PM, Antoine Pelisse apeli...@gmail.com wrote: On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey bca...@nvidia.com wrote: --- This email message is for the sole use of the intended recipient

Re: [PATCH 2/2] Don't close pack fd when free'ing pack windows

On Wed, Jul 31, 2013 at 2:21 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Wed, Jul 31, 2013 at 11:08:21PM +0200, Antoine Pelisse wrote: On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey bca...@nvidia.com wrote

Re: [PATCH] sha1_file: introduce close_one_pack() to close packs on fd pressure

On Tue, Jul 30, 2013 at 12:52 PM, Jeff King p...@peff.net wrote: On Tue, Jul 30, 2013 at 08:39:48AM -0700, Junio C Hamano wrote: Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com When the number of open packs exceeds pack_max_fds, unuse_one_window

[PATCH] sha1_file: introduce close_one_pack() to close packs on fd pressure

From: Brandon Casey draf...@gmail.com When the number of open packs exceeds pack_max_fds, unuse_one_window() is called repeatedly to attempt to release the least-recently-used pack windows, which, as a side-effect, will also close a pack file after closing its last open window. If a pack file

Re: [PATCHv3 10/10] pack-revindex: radix-sort the revindex

nice. For what it's worth: Reviewed-by: Brandon Casey draf...@gmail.com remainder retained for reference (or whatever Jonathan usually says) The interdiff is: diff --git a/pack-revindex.c b/pack-revindex.c index 9365bc2..b4d2b35 100644 --- a/pack-revindex.c +++ b/pack-revindex.c

Re: [PATCH 10/10] pack-revindex: radix-sort the revindex

On Wed, Jul 10, 2013 at 4:55 AM, Jeff King p...@peff.net wrote: The pack revindex stores the offsets of the objects in the pack in sorted order, allowing us to easily find the on-disk size of each object. To compute it, we populate an array with the offsets from the sha1-sorted idx file, and

[PATCH v2] remote.c: avoid O(m*n) behavior in match_push_refs

of local refs), so the overhead of creating the search index would likely exceed the benefit of using it. Signed-off-by: Brandon Casey draf...@gmail.com --- Here is the reroll with an updated commit message that hopefully provides a little more detail to justify this change. I removed the use

[PATCH v2 w/prune index] remote.c: avoid O(m*n) behavior in match_push_refs

. A similar operation is performed in the reverse direction when pruning using a matching or pattern refspec. Let's avoid O(m*n) behavior in the same way by lazily preparing an index on the local refs. Signed-off-by: Brandon Casey draf...@gmail.com --- On Mon, Jul 8, 2013 at 12:50 AM, Jeff King p

Re: [PATCH 4/4] pack-revindex: radix-sort the revindex

On Sun, Jul 7, 2013 at 3:14 AM, Jeff King p...@peff.net wrote: The pack revindex stores the offsets of the objects in the pack in sorted order, allowing us to easily find the on-disk size of each object. To compute it, we populate an array with the offsets from the sha1-sorted idx file, and

Re: [PATCH 4/4] pack-revindex: radix-sort the revindex

On Mon, Jul 8, 2013 at 1:50 PM, Brandon Casey draf...@gmail.com wrote: On Sun, Jul 7, 2013 at 3:14 AM, Jeff King p...@peff.net wrote: diff --git a/pack-revindex.c b/pack-revindex.c index 77a0465..d2adf36 100644 --- a/pack-revindex.c +++ b/pack-revindex.c @@ -59,11 +59,78 @@ static int

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On Tue, Jul 2, 2013 at 11:23 PM, Jeff King p...@peff.net wrote: On Tue, Jul 02, 2013 at 04:53:48PM -0700, Brandon Casey wrote: From: Brandon Casey draf...@gmail.com When pushing, each ref in the local repository must be paired with a ref advertised by the remote server. Currently

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On 7/3/2013 11:40 AM, Junio C Hamano wrote: Brandon Casey draf...@gmail.com writes: Right. For repos with few refs on either side, I don't think there will be any measurable difference. When pushing a single ref to a repo with a very large number of refs, we will see a very small net loss

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On 7/3/2013 12:00 PM, Jeff King wrote: On Wed, Jul 03, 2013 at 11:40:12AM -0700, Junio C Hamano wrote: Brandon Casey draf...@gmail.com writes: Right. For repos with few refs on either side, I don't think there will be any measurable difference. When pushing a single ref to a repo

Re: How to still kill git fetch with too many refs

On Mon, Jul 1, 2013 at 10:01 PM, Jeff King p...@peff.net wrote: On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote: I replicated your test setup, and the problem is that we have many common objects on both sides during the ref negotiation. So we end up in rev_list_push for each one,

[PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

From: Brandon Casey draf...@gmail.com When pushing, each ref in the local repository must be paired with a ref advertised by the remote server. Currently, this is performed by first applying the refspec to the local ref to transform the local ref into the name of the remote ref

Re: [PATCH] http.c: don't rewrite the user:passwd string multiple times

On Mon, Jun 17, 2013 at 10:19 PM, Jeff King p...@peff.net wrote: On Mon, Jun 17, 2013 at 07:00:40PM -0700, Brandon Casey wrote: Curl requires that we manage any strings that we pass to it as pointers. So, we should not be overwriting this strbuf after we've passed it to curl. My

[PATCH v2] http.c: don't rewrite the user:passwd string multiple times

From: Brandon Casey draf...@gmail.com Curl older than 7.17 (RHEL 4.X provides 7.12 and RHEL 5.X provides 7.15) requires that we manage any strings that we pass to it as pointers. So, we really shouldn't be modifying this strbuf after we have passed it to curl. Our interaction with curl

[PATCH 1/2] builtin/checkout.c: don't leak memory in check_tracking_name

From: Brandon Casey draf...@gmail.com remote_find_tracking() populates the query struct with an allocated string in the dst member. So, we do not need to xstrdup() the string, since we can transfer ownership from the query struct (which will go out of scope at the end of this function) to our

[PATCH 2/2] t/t9802: explicitly name the upstream branch to use as a base

From: Brandon Casey draf...@gmail.com Prior to commit fa83a33b, the 'git checkout' DWIMery would create a new local branch if the specified branch name did not exist and it matched exactly one ref in the remotes namespace. It searched the remotes namespace for matching refs using a simple

[PATCH] http.c: don't rewrite the user:passwd string multiple times

From: Brandon Casey draf...@gmail.com Curl requires that we manage any strings that we pass to it as pointers. So, we should not be overwriting this strbuf after we've passed it to curl. Additionally, it is unnecessary since we only prompt for the user name and password once, so we end up

Re: [PATCH] Documentation/CommunityGuidelines

On Tue, Jun 11, 2013 at 7:40 AM, Michael Haggerty mhag...@alum.mit.edu wrote: At the risk of being presumptuous myself, I suggest that you show a copy of your email to somebody whom you know and respect in the real world, somebody who is not immersed in the Git community meltdown. For

Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}

On Tue, Apr 16, 2013 at 11:09 AM, Ramkumar Ramachandra artag...@gmail.com wrote: While a 'git stash show stash^{/quuxery}' works just fine, a 'git stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a stash reference'. I don't think it is appropriate to use the ^{/text}

Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}

On Tue, Apr 16, 2013 at 12:11 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey draf...@gmail.com writes: The stash is implemented using the reflog. The ^{/text} notation searches the commit history, not the reflog. So I think it will be able to match the first entry in your stash

  1   2   3   >