Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

On 12/05/2015 08:44 AM, Jeff King wrote: > [...] > I think the config option needs to be extensions.refsBackendType, too, > per the logic in 00a09d5 (introduce "extensions" form of > core.repositoryformatversion, 2015-06-23). And I guess it needs to bump > core.repositoryformatversion to "1". I

Re: Building Git with HTTPS support: avoiding libcurl?

On Tue, 22 Dec 2015, Paul Smith wrote: I grok that Git doesn't want to re-invent the wheel and that libcurl is convenient. I just wonder if anyone knows of another wheel, that doesn't come attached to an entire tractor-trailer, that could be used instead :). But if you would consider

Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

On Wed, Dec 23, 2015 at 4:37 PM, Jeff King wrote: > On Tue, Dec 22, 2015 at 10:13:03AM -0800, Junio C Hamano wrote: > >> > Another by the way, this "forcing aliases as external commands" now >> > shows something like "error: git-log died of signal 13" when the pager >> > exits

[PATCH] clone: use child_process for recursive checkouts

Signed-off-by: Michael Haggerty --- David, I think if you insert this patch before your 13/16 refs: allow ref backend to be set for clone , then the hunk in builtin/clone.c:checkout() of your patch becomes trivial: if (refs_backend_type)

Announcing release for Git 1.9 on CentOS Linux 6 and 7 x86_64 SCL

I am pleased to announce the immediate availability of Git 1.9 on CentOS Linux 6 and 7 x86_64, delivered via a Software Collection (SCL) built by the SCLo Special Interest Group (https://wiki.centos.org/SpecialInterestGroup/SCLo). QuickStart -- You can get started in three easy steps:

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

On 12/03/2015 01:35 AM, David Turner wrote: > git init learns a new argument --refs-backend-type. Presently, only > "files" is supported, but later we will add other backends. > > When this argument is used, the repository's core.refsBackendType > configuration value is set, and the refs

Re: [PATCH 14/16] refs: allow ref backend to be set for clone

On 12/03/2015 01:35 AM, David Turner wrote: > Add a new option, --refs-backend-type, to allow the ref backend type to > be set on new clones. > > Submodules must use the same ref backend as the parent repository, so ^^^ is this verified anywhere? Hint: if not, it probably should be. For example,

[PATCH 01/10] t/t5303-pack-corruption-resilience.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 03/10] t/t5305-include-tag.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 04/10] t/t5500-fetch-pack.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 09/10] t/t5516-fetch-push.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 08/10] t/t5515-fetch-merge-logic.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 06/10] t/t5506-remote-groups.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 05/10] t/t5505-remote.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 07/10] t/t5510-fetch.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 02/10] t/t5304-prune.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 10/10] t/t5517-push-mirror.sh: use the $( ... ) construct for command substitution

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular,

[PATCH 00/10] use the $( ... ) construct for command substitution

This patch series continues the changes introduced with the merge 6753d8a85d543253d95184ec2faad6dc197f248: Merge branch 'ep/shell-command-substitution' Adjust shell scripts to use $(cmd) instead of `cmd`. This is the fourth serie, the other will be sent separately. Elia Pinto (10):

Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

On Wed, Dec 23, 2015 at 4:37 AM, Jeff King wrote: > Subject: [PATCH] avoid SIGPIPE warnings for aliases > > When git executes an alias that specifies an external > command, it will complain if the alias dies due to a signal. > This is usually a good thing, as signal deaths are >

Re: [PATCH 15/16] refs: add LMDB refs backend

On 12/03/2015 01:35 AM, David Turner wrote: > Add a database backend for refs using LMDB. This backend runs git > for-each-ref about 30% faster than the files backend with fully-packed > refs on a repo with ~120k refs. It's also about 4x faster than using > fully-unpacked refs. In addition, and

Re: Building Git with HTTPS support: avoiding libcurl?

Hi Daniel, On Wed, 23 Dec 2015, Daniel Stenberg wrote: > By re-using a very widely used, well developed and properly documented > library [libcurl] (yeah, I claim it is but you don't need to take my > word for it) that is available everywhere - git benefits. For what it's worth, I fully agree.

Re: [PATCH 14/16] refs: allow ref backend to be set for clone

On Wed, Dec 23, 2015 at 8:51 AM, Michael Haggerty wrote: > On 12/03/2015 01:35 AM, David Turner wrote: >> + if (refs_backend_type && *refs_backend_type) { >> + argv_array_push(, "--refs-backend-type"); >> + argv_array_push(, refs_backend_type); >>

Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

Am 23.12.2015 um 10:37 schrieb Jeff King: The second line comes from handle_alias itself. It calls die_errno whenever run_command returns a negative value. However, only -1 indicates a syscall error where errno has something useful (note that it says the useless "success" above). Instead, we

[PATCH] user-manual: remove temporary branch entry from todo list

Remove the suggestion for using a detached HEAD instead of a temporary branch. Signed-off-by: Stephen P. Smith --- Notes: A search of the user manual found only one location which refers to temporary branches. This has to do with how Tony Luck uses them. Even

Re: RefTree: Alternate ref backend

Michael Haggerty writes: > You are answering "What is 'refs/' good for in the pathnames of files > that store loose references?" I was asking "What is 'refs/' good for in > the logical names of references?" > > It would have been totally possible to make the full name of a

Re: [PATCH 7/8] config: add core.untrackedCache

Junio C Hamano writes: > Duy Nguyen writes: > >> In that case we can just check config once in read_index_from and >> destroy UNTR extension. Or the middle ground, we check config once in >> that place, make a note in struct index_state, and make

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

On Wed, Dec 23, 2015 at 10:52:41AM +0100, Michael Haggerty wrote: > On 12/05/2015 08:44 AM, Jeff King wrote: > > [...] > > I think the config option needs to be extensions.refsBackendType, too, > > per the logic in 00a09d5 (introduce "extensions" form of > > core.repositoryformatversion,

[PATCH v3 01/11] dir: free untracked cache when removing it

Signed-off-by: Christian Couder --- builtin/update-index.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/update-index.c b/builtin/update-index.c index 7431938..a6fff87 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c @@ -1123,6 +1123,7 @@

[PATCH v3 02/11] update-index: use enum for untracked cache options

Signed-off-by: Christian Couder --- builtin/update-index.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index a6fff87..1e546a3 100644 --- a/builtin/update-index.c +++

[PATCH v3 03/11] update-index: add --test-untracked-cache

It is nice to just be able to test if untracked cache is supported without enabling it. Signed-off-by: Christian Couder --- Documentation/git-update-index.txt | 9 - builtin/update-index.c | 5 + 2 files changed, 13 insertions(+), 1 deletion(-)

[PATCH v3 05/11] update-index: move 'uc' var declaration

Signed-off-by: Christian Couder --- builtin/update-index.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index c91e695..f667125 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c @@

Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

On Wed, Dec 23, 2015 at 09:37:04PM +0100, Johannes Sixt wrote: > >--- a/git.c > >+++ b/git.c > >@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv) > > alias_argv[argc] = NULL; > > > > ret = run_command_v_opt(alias_argv,

[PATCH v3 10/11] config: add core.untrackedCache

When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. Also when we know that mtime is not supported by the environment, for example because the repo is shared

[PATCH v3 09/11] dir: simplify untracked cache "ident" field

It is not a good idea to compare kernel versions and disable the untracked cache if it changes as people may upgrade and still want the untracked cache to work. So let's just compare work tree locations to decide if we should disable it. Also it's not useful to store many locations in the ident

[PATCH v3 06/11] dir: add add_untracked_cache()

Factor out code into add_untracked_cache(), which will be used in a later commit. Signed-off-by: Christian Couder --- builtin/update-index.c | 11 +-- dir.c | 14 ++ dir.h | 1 + 3 files changed, 16 insertions(+),

[PATCH v3 07/11] dir: add new_untracked_cache()

Factor out code into new_untracked_cache(), which will be used multiple times in a later commit. Signed-off-by: Christian Couder --- dir.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/dir.c b/dir.c index

[PATCH v3 08/11] dir: add remove_untracked_cache()

Factor out code into remove_untracked_cache(), which will be used in a later commit. Signed-off-by: Christian Couder --- builtin/update-index.c | 6 +- dir.c | 9 + dir.h | 1 + 3 files changed, 11 insertions(+), 5

[PATCH v3 11/11] t7063: add tests for core.untrackedCache

Signed-off-by: Christian Couder --- t/t7063-status-untracked-cache.sh | 48 +-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh index

[PATCH v3 04/11] update-index: add untracked cache notifications

Attempting to flip the untracked-cache feature on for a random index file with cd /random/unrelated/place git --git-dir=/somewhere/else/.git update-index --untracked-cache would not work as you might expect. Because flipping the feature on in the index also records the location of the

Re: [PATCH v3 07/11] dir: add new_untracked_cache()

On Wed, Dec 23, 2015 at 4:03 PM, Christian Couder wrote: > Factor out code into new_untracked_cache(), which will be used > multiple times in a later commit. Odd indentation: s/^\s+// > Signed-off-by: Christian Couder > --- > diff

[PATCH V4 2/2] user-manual: add section documenting shallow clones

Rather than merely pointing readers at the 1.5 release notes to learn about shallow clones, document them formally. Signed-off-by: Stephen P. Smith --- I replaced the paragraphs that I wrote with Eric Shunshine's since it was cleaner. I like the idea of linking to the

Re: [PATCH v2 09/11] ref-filter: introduce remote_ref_atom_parser()

On Thu, Dec 17, 2015 at 2:52 PM, Eric Sunshine wrote: > On Wed, Dec 16, 2015 at 10:30 AM, Karthik Nayak wrote: >> Introduce remote_ref_atom_parser() which will parse the '%(upstream)' >> and '%(push)' atoms and store information into the

Re: [PATCH v3 07/11] dir: add new_untracked_cache()

On Wed, Dec 23, 2015 at 11:53 PM, Eric Sunshine wrote: > On Wed, Dec 23, 2015 at 4:03 PM, Christian Couder > wrote: >> Factor out code into new_untracked_cache(), which will be used >> multiple times in a later commit. > > Odd

Re: Combining APPLE_COMMON_CRYPTO=1 and NO_OPENSSL=1 produces unexpected result

On Wed, Nov 25, 2015 at 10:10 AM, Jack Nagel wrote: > When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the > default) and specifying NO_OPENSSL=1, the resulting git uses the > BLK_SHA1 implementation rather than the functions available in > CommonCrypto. > > $ make

Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

On Tue, Dec 22, 2015 at 10:13:03AM -0800, Junio C Hamano wrote: > > Another by the way, this "forcing aliases as external commands" now > > shows something like "error: git-log died of signal 13" when the pager > > exits early, for an alias like "l1 = log --oneline". > > ... and we do not show

Re: [PATCH 12/16] refs: always handle non-normal refs in files backend

On 12/03/2015 01:35 AM, David Turner wrote: > Always handle non-normal (per-worktree or pseudo) refs in the files > backend instead of alternate backends. > > Sometimes a ref transaction will update both a per-worktree ref and a > normal ref. For instance, an ordinary commit might update >