Shallow submodule efficiency

Hi! I have the feeling that “git submodule update --depth 1” is less clever than it could be. Here is one example I observed with git 2.0.0: git init foo cd foo git clone --single-branch \ -b v0.99 https://github.com/git/git.git git-scm git submodule add

Re: [PATCH v2] Refactor recv_sideband()

Lukas Fleischer writes: > I do not see how using fwrite() buys us anything. Neither fwrite() nor > fputs() nor fprintf() guarantee to call write() only once. That is not the point. Your first attempt split what used to be a single fprintf(), which (as Nico explained)

[PATCH v4] Refactor recv_sideband()

Before this patch, we used character buffer manipulations to split messages from the sideband at line breaks and insert "remote: " at the beginning of each line, using the packet size to determine the end of a message. However, since it is safe to assume that diagnostic messages from the sideband

Re: [PATCH v2] Refactor recv_sideband()

On Mon, 27 Jun 2016 at 22:47:59, Nicolas Pitre wrote: > On Mon, 27 Jun 2016, Lukas Fleischer wrote: > > > On Mon, 27 Jun 2016 at 19:50:13, Junio C Hamano wrote: > > > Jeff King writes: > > > > > > > On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote: > > > > > > > >>

[PATCH] submodule: test moving recursive submodule

Signed-off-by: Stefan Beller --- This tries to reproduce the error as pointed out in http://stackoverflow.com/questions/32782382/git-moving-submodules-recursively-nested-submodules but the tests pass. This still seems to be missing a detail. Bart any idea how this setup may

What's cooking in git.git (Jun 2016, #09; Mon, 27)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The first batch for this cycle

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

Jeff King wrote: > On Mon, Jun 27, 2016 at 05:49:48PM -0400, Jeff King wrote: > > > So in general I would say that handing non-blocking descriptors to git > > is not safe. Indeed. This also makes me wonder if our output to stdout/stderr suffer from the same theoretical problems

Re: [PATCH] builtin/worktree.c: add option for setting worktree name

On Mon, Jun 27, 2016 at 1:52 AM, Barret Rennie wrote: > On Jun 26, 2016, at 5:00 PM, Eric Sunshine wrote: >> One thing which hasn't been explained, and about which I'm still >> confused even after reading this thread in its entirety, is what >> Barret

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

On Mon, Jun 27, 2016 at 05:49:48PM -0400, Jeff King wrote: > So in general I would say that handing non-blocking descriptors to git > is not safe. I think it's possible to loop on getdelim() when we see > EAGAIN, but I'm not sure if it's worth it. The patch for that is below, for the curious. It

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

On Mon, Jun 27, 2016 at 08:13:11PM +, Eric Wong wrote: > > Quite a while ago, when I started doing code reviews professionally, I > > wondered > > if the code review procedure can be semi-automated, as automation helps > > keeping > > the error rate low. By that I mean having a check list

Re: Git mv -- submodule -- recursive

On Mon, Jun 27, 2016 at 1:07 PM, Bart Bogaerts wrote: > Hi, > > I tested this on git version 2.9 and it still fails (exactly the same > behaviour as on the stackoverflow post; also the workarounded I posted > there still works). I see. the commit I referenced was solving

Re: [PATCH v2] Refactor recv_sideband()

On Mon, 27 Jun 2016, Lukas Fleischer wrote: > On Mon, 27 Jun 2016 at 19:50:13, Junio C Hamano wrote: > > Jeff King writes: > > > > > On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote: > > > > > >> It's just you used xwrite() there that introduced a different issue. >

Re: [PATCH v2] Refactor recv_sideband()

On Mon, 27 Jun 2016 at 19:50:13, Junio C Hamano wrote: > Jeff King writes: > > > On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote: > > > >> It's just you used xwrite() there that introduced a different issue. > >> Wouldn't replacing it with fwrite(stderr) without

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

Stefan Beller wrote: > On Mon, Jun 27, 2016 at 7:36 AM, Jeff King wrote: > > It's also true that our error rate will never be 0%. So some bugs will > > always slip through, some review comments will be forgotten, etc. Eric > > did find and fix the bug just now,

Re: Git mv -- submodule -- recursive

Hi, I tested this on git version 2.9 and it still fails (exactly the same behaviour as on the stackoverflow post; also the workarounded I posted there still works). Some output showing the bug follows below: bartb@EB-Latitude-E5450 ~/Documents/papers $ git status On branch master Your branch is

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

On Mon, Jun 27, 2016 at 12:43:32PM -0700, Stefan Beller wrote: > There are a few issues: > > 1) How did you spot the bug? ("Experience/Logical thinking" is the hand > wavy answer, but if you had a list like > [ ] check for mem leak > [ ] check for futureproof design >

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

On Mon, Jun 27, 2016 at 12:17 PM, Jeff King wrote: > On Mon, Jun 27, 2016 at 09:49:06AM -0700, Stefan Beller wrote: > >> Quite a while ago, when I started doing code reviews professionally, I >> wondered if the code review procedure can be semi-automated, as >> automation helps

Re: [PATCH/RFC 3/3] diff.c: add --relative-names to be used with --name-only

On Mon, Jun 27, 2016 at 9:35 PM, Jeff King wrote: > On Mon, Jun 27, 2016 at 09:33:18PM +0200, Duy Nguyen wrote: > >> On Mon, Jun 27, 2016 at 9:24 PM, Jeff King wrote: >> > On Sun, Jun 26, 2016 at 07:16:16PM +0200, Nguyễn Thái Ngọc Duy wrote: >> > >> >> The

Re: [PATCH] gc: fix off-by-one error with gc.autoPackLimit

On Sat, Jun 25, 2016 at 06:46:47AM +, Eric Wong wrote: > This matches the documentation and allows gc.autoPackLimit=1 > to maintain a single pack without attempting a repack on every > "git gc --auto" invocation. > > Signed-off-by: Eric Wong > --- > builtin/gc.c | 2 +- > 1

Re: [PATCH/RFC 3/3] diff.c: add --relative-names to be used with --name-only

On Mon, Jun 27, 2016 at 09:33:18PM +0200, Duy Nguyen wrote: > On Mon, Jun 27, 2016 at 9:24 PM, Jeff King wrote: > > On Sun, Jun 26, 2016 at 07:16:16PM +0200, Nguyễn Thái Ngọc Duy wrote: > > > >> The difference with --relative option is, this option does not filter > >> paths

Re: [PATCH] connect: read $GIT_SSH_COMMAND from config file

On Sun, Jun 26, 2016 at 01:16:35PM +0200, Nguyễn Thái Ngọc Duy wrote: > Similar to $GIT_ASKPASS or $GIT_PROXY_COMMAND, we also read from > config file first then fall back to $GIT_SSH_COMMAND. > > This is useful for selecting different private keys targetting the > same host (e.g. github) > >

Re: [PATCH/RFC 3/3] diff.c: add --relative-names to be used with --name-only

On Mon, Jun 27, 2016 at 9:24 PM, Jeff King wrote: > On Sun, Jun 26, 2016 at 07:16:16PM +0200, Nguyễn Thái Ngọc Duy wrote: > >> The difference with --relative option is, this option does not filter >> paths outside cwd. You can add two more chars " ." on your command >> line for

Re: [PATCH v4 0/5] Better ref summary alignment in "git fetch"

On Mon, Jun 27, 2016 at 02:43:54PM -0400, Jeff King wrote: > On Sun, Jun 26, 2016 at 07:58:05AM +0200, Nguyễn Thái Ngọc Duy wrote: > > > v4 is a cleaned up version of v3. Tests are added. Typos in > > git-fetch.txt are corrected. The "{ -> origin/}master" format is > > dropped. > > Thanks for

Re: [PATCH/RFC 3/3] diff.c: add --relative-names to be used with --name-only

On Sun, Jun 26, 2016 at 07:16:16PM +0200, Nguyễn Thái Ngọc Duy wrote: > The difference with --relative option is, this option does not filter > paths outside cwd. You can add two more chars " ." on your command > line for that. Another difference seems to be that it applies only to --name-only,

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

On Mon, Jun 27, 2016 at 09:49:06AM -0700, Stefan Beller wrote: > Quite a while ago, when I started doing code reviews professionally, I > wondered if the code review procedure can be semi-automated, as > automation helps keeping the error rate low. By that I mean having a > check list which I can

Re: [PATCH 3/6] doc: typeset -- as litteral

On Mon, Jun 27, 2016 at 07:46:20PM +0200, Matthieu Moy wrote: > Subject: Re: [PATCH 3/6] doc: typeset -- as litteral s/litteral/literal/ I can hardly blame you, though. I think English stole the word from French and then switched its spelling. :) You may also want put quotes around "--" to

Re: [PATCH 2/6] doc: typeset long command-line options as literal

On Mon, Jun 27, 2016 at 07:46:19PM +0200, Matthieu Moy wrote: > Similarly to the previous commit, use backquotes instead of > forward-quotes, for long options. > > This was obtained with: > > perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt > > and manual tweak to remove false positive

Re: [PATCH 1/6] doc: typeset short command-line options as literal

On Mon, Jun 27, 2016 at 07:46:18PM +0200, Matthieu Moy wrote: > It was common in our documentation to surround short option names with > forward quotes, which renders as italic in HTML. Instead, use backquotes > which renders as monospace. This is one more step toward conformance to >

Re: [PATCH v4 0/5] Better ref summary alignment in "git fetch"

On Sun, Jun 26, 2016 at 07:58:05AM +0200, Nguyễn Thái Ngọc Duy wrote: > v4 is a cleaned up version of v3. Tests are added. Typos in > git-fetch.txt are corrected. The "{ -> origin/}master" format is > dropped. Thanks for continuing to look into this. I tried it on my most-horrible example case,

Re: [PATCH v8 00/41] libify apply and use lib in am, part 2

On Mon, Jun 27, 2016 at 8:23 PM, Christian Couder wrote: > > I will send a diff between this version and the previous one, as a > reply to this email. Here is the diff: diff --git a/apply.c b/apply.c index 98a..2ac22d3 100644 --- a/apply.c +++ b/apply.c @@

[PATCH v8 17/41] builtin/apply: make gitdiff_*() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", gitdiff_*() functions should return -1 instead of calling die(). A previous patch made it possible for

[PATCH v8 10/41] builtin/apply: move init_apply_state() to apply.c

To libify `git apply` functionality we must make init_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into a new "apply.c". Helped-by: Eric Sunshine Signed-off-by: Christian Couder --- Makefile| 1 + apply.c

[PATCH v8 18/41] builtin/apply: change die_on_unsafe_path() to check_unsafe_path()

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", die_on_unsafe_path() should return a negative integer instead of calling die(), so while doing that let's

[PATCH v8 05/41] builtin/apply: make find_header() return -128 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, let's make find_header() return -128 instead of calling die(). We could make it return -1, unfortunately

[PATCH v8 07/41] builtin/apply: make parse_single_patch() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_single_patch() should return a negative integer instead of calling die(). Let's do that by using error()

[PATCH v8 21/41] builtin/apply: make add_conflicted_stages_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_conflicted_stages_file() should return -1 instead of calling die(). Helped-by: Eric Sunshine

[PATCH v8 11/41] apply: make init_apply_state() return -1 instead of exit()ing

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", init_apply_state() should return -1 instead of calling exit(). Signed-off-by: Christian Couder

[PATCH v8 34/41] apply: add 'be_silent' variable to 'struct apply_state'

This variable should prevent anything to be printed on both stderr and stdout. Let's not take care of stdout and apply_verbosely for now though, as that will be taken care of in following patches. Signed-off-by: Christian Couder --- apply.c | 43

[PATCH v8 09/41] builtin/apply: make parse_ignorewhitespace_option() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", parse_ignorewhitespace_option() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v8 39/41] apply: change error_routine when be_silent is set

To avoid printing anything when applying with be_silent set, let's save the existing warn and error routines before applying and replace them with a routine that does nothing. Then after applying, let's restore the saved routines. Signed-off-by: Christian Couder ---

[PATCH v8 38/41] usage: add get_error_routine() and get_warn_routine()

Let's make it possible to get the current error_routine and warn_routine, so that we can store them before using set_error_routine() or set_warn_routine() to use new ones. This way we will be able put back the original routines, when we are done with using new ones. Signed-off-by: Christian

[PATCH v8 35/41] apply: make 'be_silent' incompatible with 'apply_verbosely'

It should be an error to have both be_silent and apply_verbosely set, so let's check that in check_apply_state(). And by the way let's not automatically set apply_verbosely when be_silent is set. Signed-off-by: Christian Couder --- apply.c | 9 +++-- 1 file

[PATCH v8 26/41] builtin/apply: make try_create_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", try_create_file() should return -1 in case of error. Unfortunately try_create_file() currently returns -1 to

[PATCH v8 23/41] builtin/apply: make create_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", create_file() should just return what add_conflicted_stages_file() and add_index_file() are returning

[PATCH v8 40/41] builtin/am: use apply api in run_apply()

This replaces run_apply() implementation with a new one that uses the apply api that has been previously prepared in apply.c and apply.h. This shoud improve performance a lot in certain cases. As the previous implementation was creating a new `git apply` process to apply each patch, it could be

[PATCH v8 32/41] environment: add set_index_file()

Introduce set_index_file() to be able to temporarily change the index file. It should be used like this: /* Save current index file */ old_index_file = get_index_file(); set_index_file((char *)tmp_index_file); /* Do stuff that will use tmp_index_file as the index file */ ...

[PATCH v8 33/41] write_or_die: use warning() instead of fprintf(stderr, ...)

In write_or_whine_pipe() and write_or_whine() when write_in_full() returns an error, let's print the errno related error message using warning() instead of fprintf(stderr, ...). This makes it possible to change the way it is handled by changing the current warn routine in usage.c. Signed-off-by:

[PATCH v8 15/41] builtin/apply: make parse_traditional_patch() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", parse_traditional_patch() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v8 04/41] builtin/apply: read_patch_file() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. Let's do that by returning -1 instead of die()ing in read_patch_file(). Signed-off-by: Christian Couder --- builtin/apply.c | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCH v8 29/41] apply: rename and move opt constants to apply.h

The constants for the "inaccurate-eof" and the "recount" options will be used in both "apply.c" and "builtin/apply.c", so they need to go into "apply.h", and therefore they need a name that is more specific to the API they belong to. Signed-off-by: Christian Couder ---

[PATCH v8 31/41] apply: make some parsing functions static again

Some parsing functions that were used in both "apply.c" and "builtin/apply.c" are now only used in the former, so they can be made static to "apply.c". Signed-off-by: Christian Couder --- apply.c | 6 +++--- apply.h | 5 - 2 files changed, 3 insertions(+), 8

[PATCH v8 37/41] usage: add set_warn_routine()

There are already set_die_routine() and set_error_routine(), so let's add set_warn_routine() as this will be needed in a following commit. Signed-off-by: Christian Couder --- git-compat-util.h | 1 + usage.c | 5 + 2 files changed, 6 insertions(+) diff

[PATCH v8 13/41] builtin/apply: move check_apply_state() to apply.c

To libify `git apply` functionality we must make check_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into "apply.c". Signed-off-by: Christian Couder --- apply.c | 32 apply.h | 1 +

[PATCH v8 36/41] apply: don't print on stdout when be_silent is set

This variable should prevent anything to be printed on both stderr and stdout. Signed-off-by: Christian Couder --- apply.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/apply.c b/apply.c index 1435f85..e2acc18 100644 --- a/apply.c +++

[PATCH v8 24/41] builtin/apply: make write_out_one_result() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", write_out_one_result() should just return what remove_file() and create_file() are returning instead of

[PATCH v8 27/41] builtin/apply: make create_one_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", create_one_file() should return -1 instead of calling exit(). Signed-off-by: Christian Couder

[PATCH v8 25/41] builtin/apply: make write_out_results() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", write_out_results() should return -1 instead of calling exit(). Helped-by: Eric Sunshine

[PATCH v8 20/41] builtin/apply: make remove_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", remove_file() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v8 41/41] apply: use error_errno() where possible

To avoid possible mistakes and to uniformly show the errno related messages, let's use error_errno() where possible. Signed-off-by: Christian Couder --- apply.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/apply.c b/apply.c

[PATCH v8 08/41] builtin/apply: make parse_whitespace_option() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_whitespace_option() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v8 16/41] builtin/apply: make gitdiff_*() return 1 at end of header

The gitdiff_*() functions that are called as p->fn() in parse_git_header() should return 1 instead of -1 in case of end of header or unrecognized input, as these are not real errors. It just instructs the parser to break out. This makes it possible for gitdiff_*() functions to return -1 in case

[PATCH v8 28/41] builtin/apply: rename option parsing functions

As these functions are going to be part of the libified apply api, let's give them a name that is more specific to the apply api. Signed-off-by: Christian Couder --- builtin/apply.c | 40 1 file changed, 20 insertions(+), 20

[PATCH v8 14/41] builtin/apply: make apply_all_patches() return 128 or 1 on error

To finish libifying the apply functionality, apply_all_patches() should not die() or exit() in case of error, but return either 128 or 1, so that it gives the same exit code as when die() or exit(1) is called. This way scripts relying on the exit code don't need to be changed. While doing that we

[PATCH v8 12/41] builtin/apply: make check_apply_state() return -1 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", check_apply_state() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v8 01/41] apply: make some names more specific

To prepare for some structs and constants being moved from builtin/apply.c to apply.h, we should give them some more specific names to avoid possible name collisions in th global namespace. Signed-off-by: Christian Couder --- builtin/apply.c | 20 ++-- 1

[PATCH v8 19/41] builtin/apply: make build_fake_ancestor() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", build_fake_ancestor() should return -1 instead of calling die(). Helped-by: Eric Sunshine

[PATCH v8 22/41] builtin/apply: make add_index_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_index_file() should return -1 instead of calling die(). Signed-off-by: Christian Couder

[PATCH v8 02/41] apply: move 'struct apply_state' to apply.h

To libify `git apply` functionality we must make 'struct apply_state' usable outside "builtin/apply.c". Let's do that by creating a new "apply.h" and moving 'struct apply_state' there. Signed-off-by: Christian Couder --- apply.h | 100

[PATCH v8 03/41] builtin/apply: make apply_patch() return -1 or -128 instead of die()ing

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. As a first step in this direction, let's make apply_patch() return -1 or -128 in case of errors instead of dying. For now its only caller apply_all_patches() will exit(128) when apply_patch() return

[PATCH v8 06/41] builtin/apply: make parse_chunk() return a negative integer on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing or exit()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_chunk() should return a negative integer instead of calling die() or exit(). As

[PATCH v8 00/41] libify apply and use lib in am, part 2

Goal This is a patch series about libifying `git apply` functionality, and using this libified functionality in `git am`, so that no 'git apply' process is spawn anymore. This makes `git am` significantly faster, so `git rebase`, when it uses the am backend, is also significantly faster.

Re: [PATCH 1/2] Support for $FILENAMES in tool definitions

On 27 June 2016 at 19:53, Junio C Hamano wrote: > Jakub Narębski writes: > >> On 2016-06-27, Alex Riesen wrote: >> >>> This adds a FILENAMES environment variable, which contains the repository >>> pathnames of all selected files the list. >>> The variable

Re: [PATCH 1/2] Support for $FILENAMES in tool definitions

Jakub Narębski writes: > On 2016-06-27, Alex Riesen wrote: > >> This adds a FILENAMES environment variable, which contains the repository >> pathnames of all selected files the list. >> The variable contains the names separated by spaces. > > Why not separate filenames with

Re: [PATCH v2] Refactor recv_sideband()

Jeff King writes: > On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote: > >> It's just you used xwrite() there that introduced a different issue. >> Wouldn't replacing it with fwrite(stderr) without changing anything >> else solve that? > > I am having trouble actually

[PATCH 2/6] doc: typeset long command-line options as literal

Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by:

[PATCH 6/6] doc: typeset HEAD and variants as litteral

This is an application of the newly added CodingGuidelines to HEAD and variants like FETCH_HEAD. It was obtained with: perl -pi -e "s/'([A-Z_]*HEAD)'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy --- Documentation/git-bisect.txt| 2 +-

[PATCH 4/6] doc: typeset long options with argument as litteral

We previously reformatted '--option' to `--option`. This patch reformats '--option ' to `--option `. Obtained with perl -pi -e "s/'(--[a-z][a-z=<>-]* <[^>]*>)'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy --- Documentation/git-config.txt | 4 ++-- 1 file changed, 2

[PATCH 5/6] CodingGuidelines: formatting HEAD in documentation

The current practice is: git/Documentation$ git grep "'HEAD'" | wc -l 24 git/Documentation$ git grep "\`HEAD\`" | wc -l 66 Let's adopt the majority as a guideline. Signed-off-by: Matthieu Moy --- Documentation/CodingGuidelines | 5 +++-- 1 file changed, 3 insertions(+),

[PATCH 3/6] doc: typeset -- as litteral

This was obtained with perl -pi -e "s/'--'/\`--\`/g" *.txt Signed-off-by: Matthieu Moy --- Documentation/git-fast-import.txt | 4 ++-- Documentation/git-filter-branch.txt | 2 +- Documentation/rev-list-options.txt | 2 +- 3 files changed, 4 insertions(+), 4

[PATCH 1/6] doc: typeset short command-line options as literal

It was common in our documentation to surround short option names with forward quotes, which renders as italic in HTML. Instead, use backquotes which renders as monospace. This is one more step toward conformance to Documentation/CodingGuidelines. This was obtained with: perl -pi -e

Re: [PATCH 2/2] Ensure the file in the diff pane is always in the list of selected files

W dniu 2016-06-27 o 15:23, Alex Riesen pisze: > It is very confusing that the file, diff of which is displayed and which is > marked as selected in the file list, is not, in fact, selected. I.e. the array > of selected files does not contain an entry for it. > > Fixing this also improves the use

Re: [PATCH 1/2] Support for $FILENAMES in tool definitions

On 2016-06-27, Alex Riesen wrote: > This adds a FILENAMES environment variable, which contains the repository > pathnames of all selected files the list. > The variable contains the names separated by spaces. Why not separate filenames with end-of-line character (LF)? It would still be broken

Re: Git mv -- submodule -- recursive

On Sun, Jun 26, 2016 at 11:01 PM, Bart Bogaerts wrote: > With a repo structured as follows > > main-files > |- submod > |- subsubmodule > > git mv submod newlocation > > does not do what it is supposed to do. It actually breaks the git repository. > It can be fixed

Re: [PATCH v13 04/20] index-helper: new daemon for caching index and related stuff

On 06/27/2016 08:58 AM, Keith McGuigan wrote: If 'indexhelper.exitafter' is set to 0, then loop is called with idle_in_seconds == 0. It gets converted to -1, but then 'idle_in_seconds * 1000' is passed to poll(), so poll gets an argument of -1000, which it EINVALs on. Silly OS X! Will

Re: [PATCH 1/2] xread: retry after poll on EAGAIN/EWOULDBLOCK

On Mon, Jun 27, 2016 at 7:36 AM, Jeff King wrote: > On Mon, Jun 27, 2016 at 06:02:12AM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > I also wondered how we managed to miss such an obvious point in review >> > of the original patch. Sadly, we _did_

Re: [PATCH] config: add conditional include

On Mon, Jun 27, 2016 at 06:32:39PM +0200, Duy Nguyen wrote: > On Mon, Jun 27, 2016 at 6:20 PM, Jeff King wrote: > > You do allow distinguishing the suffix thing with "/" at the end in the > > rule above, though. So between the two rules: > > > > - slash at the end is a shorthand

Re: [PATCH] config: add conditional include

On Mon, Jun 27, 2016 at 6:20 PM, Jeff King wrote: > You do allow distinguishing the suffix thing with "/" at the end in the > rule above, though. So between the two rules: > > - slash at the end is a shorthand for "/**" > > - no-slash at the beginning (i.e., a non-absolute

Re: Segfault during a big messy rebase

On Mon, Jun 27, 2016 at 06:51:26AM +, Greg Werbin wrote: > I was in the middle of a big messy rebase when the following > happened: > > $ git rebase --continue > /usr/local/Cellar/git/2.9.0/libexec/git-core/git-rebase--interactive: > line 238: 60305 > Segmentation fault: 11 "$@" > Could

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

Michael Haggerty writes: > I'd like to request that the change for the p4 temprefs be made in two > steps: > > 1. Write references to `refs/git-p4-tmp` or whatever, without >worrying about making them per-worktree. > > 2. Carve out a per-worktree namespace, bikeshed

Re: [PATCH] config: add conditional include

On Sun, Jun 26, 2016 at 8:27 PM, Jeff King wrote: > On Sun, Jun 26, 2016 at 09:06:17AM +0200, Nguyễn Thái Ngọc Duy wrote: > >> If the path argument in "include" starts with "gitdir:", it is >> followed by a wildmatch pattern. The include is only effective if >> $GIT_DIR matches the

Re: [PATCH] config: add conditional include

On Mon, Jun 27, 2016 at 06:14:17PM +0200, Duy Nguyen wrote: > >> + } else if (!strchr(pattern.buf, '/')) { > >> + /* no slashes match one directory component */ > >> + strbuf_insert(, 0, "**/", 3); > >> + strbuf_addstr(,

Re: [PATCH v13 21/20] unix-socket.c: add stub implementation when unix sockets are not supported

On Mon, Jun 27, 2016 at 2:14 PM, Johannes Schindelin wrote: > Hi Duy, > > On Sun, 26 Jun 2016, Nguyễn Thái Ngọc Duy wrote: > >> This keeps #ifdef at the callee instead of caller, it's less messier. >> >> The caller in question is in read-cache.c which, unlike other >>

Re: [PATCH v2] Refactor recv_sideband()

On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote: > It's just you used xwrite() there that introduced a different issue. > Wouldn't replacing it with fwrite(stderr) without changing anything > else solve that? I am having trouble actually seeing how the ANSI-emulation code gets

Re: [RFC] Native access to Git LFS cache

larsxschnei...@gmail.com writes: > Unfortunately that fix helps only with cloning. Any local Git operation > that invokes the clean/smudge filter (e.g. switching branches) is still > slow. Do you know where the slowness comes from? Does Joey's new clean/smudge interface help GitLFS? You are

Re: [PATCH 1/2] Support for $FILENAMES in tool definitions

Hi Alex, On Mon, 27 Jun 2016, Alex Riesen wrote: > This adds a FILENAMES environment variable, which contains the repository > pathnames of all selected files the list. > The variable contains the names separated by spaces. > > Similar to the FILENAME it is broken yet, if the names contain

Re: [PATCH v13 20/20] index-helper: indexhelper.exitafter config

On Sun, Jun 26, 2016 at 7:54 PM, David Turner wrote: > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 385ea66..336d5a2 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -1860,6 +1860,10 @@ indexhelper.autorun:: >

Re: [PATCH v2] Refactor recv_sideband()

Lukas Fleischer writes: > On Fri, 24 Jun 2016 at 20:32:28, Junio C Hamano wrote: >> On Fri, Jun 24, 2016 at 11:14 AM, Jeff King wrote: >> > >> > I do wonder about the ANSI_SUFFIX thing, though. >> >> compat/winansi.c seems to have a provision for 'K' (and

Re: [RFC] Native access to Git LFS cache

On Mon, Jun 27, 2016 at 7:38 AM, wrote: > ## Proposed solution > Git LFS caches its objects under .git/lfs/objects. Most of the time Git > LFS objects are already available in the cache (e.g. if you switch branches > back and forth). I implemented these "cache hits"

Re: name for A..B ranges?

From: "Junio C Hamano" "Philip Oakley" writes: ..., I was wondering if an alternative would be to refer to it via [use the headings of] it's notation, i.e. "the 'two-dot' range notation" (or 'syntax' is that is preferred), and the "three-dot symmetric

Re: [PATCH v4 5/5] fetch: reduce duplicate in ref update status lines with placeholder

Eric Sunshine writes: > In my brain, at least, '$' is associated so strongly with regex that > "origin/$" is interpreted automatically as anchoring "origin/" at the > end of string, and "refs/$/head" just feels weird. > > On the other hand, given the familiarity of shell

  1   2   >