[PATCH v2 02/17] fetch: trivially refactor assignment to ref_nr

Trivially refactor an assignment to make a subsequent patch smaller. The "ref_nr" variable is initialized to 0 earlier, just as "j" is, and "j" is only incremented in that loop, so this change isn't a logic error. This change makes a subsequent change which splits the incrementing of "ref_nr"

[PATCH v2 01/17] fetch: don't redundantly NULL something calloc() gave us

Stop redundantly NULL-ing the last element of the refs structure, which was retrieved via calloc(), and is thus guaranteed to be pre-NULL'd. This code dates back to b888d61c83 ("Make fetch a builtin", 2007-09-10), where wasn't any reason to do this back then either, it's just boilerplate left

[PATCH v2 5/9] t5510: consolidate 'grep' and 'test_i18ngrep' patterns

One of the tests in 't5510-fetch.sh' checks the output of 'git fetch' using 'test_i18ngrep', and while doing so it prefilters the output with 'grep' before piping the result into 'test_i18ngrep'. This prefiltering is unnecessary, with the appropriate pattern 'test_i18ngrep' can do it all by

[PATCH v2 7/9] t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'

Both 'test_i18ncmp' and 'test_i18ngrep' helper functions are supposed to be called from our test scripts, so they should be in 'test-lib-functions.sh'. Signed-off-by: SZEDER Gábor --- t/test-lib-functions.sh | 26 ++ t/test-lib.sh | 26

[PATCH v2 9/9] t: make 'test_i18ngrep' more informative on failure

When 'test_i18ngrep' can't find the expected pattern, it exits completely silently; when its negated form does find the pattern that shouldn't be there, it prints the matching line(s) but otherwise exits without any error message. This leaves the developer puzzled about what could have gone

[PATCH v2 0/9] 'test_i18ngrep'-related fixes and improvements

This is the second version of 'sg/test-i18ngrep'. To recap, this patch series fixes a couple of bogus 'test_i18ngrep' invocations (patches 1-4), tries to prevent similar bugs in the future (patch 8), teaches 'test_i18ngrep' to be more informative on failure (patch 9), and a bit of cleanups in

[PATCH v2 4/9] t4001: don't run 'git status' upstream of a pipe

The primary purpose of three tests in 't4001-diff-rename.sh' is to check rename detection in 'git status', but all three do so by running 'git status' upstream of a pipe, hiding its exit code. Consequently, the test could continue even if 'git status' exited with error. Use an intermediate file

[PATCH v2 1/9] t5541: add 'test_i18ngrep's missing filename parameter

The test 'push --no-progress silences progress but not status' runs 'test_i18ngrep' without specifying a filename parameter. This has remained unnoticed since its introduction in e304aeba2 (t5541: test more combinations of --progress, 2012-05-01), because that 'test_i18ngrep' is supposed to check

[PATCH v2 6/9] t5536: let 'test_i18ngrep' read the file without redirection

Redirecting 'test_i18ngrep's standard input from a file will interfere with the linting that will be added in a later patch. Signed-off-by: SZEDER Gábor --- t/t5536-fetch-conflicts.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 8/9] t: validate 'test_i18ngrep's parameters

Some of the previous patches in this series fixed bogus 'test_i18ngrep' invocations: - Two invocations where the tested git command's standard output is directly piped into 'test_i18ngrep'. While convenient, this is an antipattern, because the pipe hides the git command's exit code,

[PATCH v2 2/9] t5812: add 'test_i18ngrep's missing filename parameter

The second 'test_i18ngrep' invocation in the test 'curl redirects respect whitelist' is missing its filename parameter. This has remained unnoticed since its introduction in f4113cac0 (http: limit redirection to protocol-whitelist, 2015-09-22), because it would only cause the test to fail if Git

[PATCH v2 3/9] t6022: don't run 'git merge' upstream of a pipe

The primary purpose of 't6022-merge-rename.sh' is to test 'git merge', but one of the tests runs it upstream of a pipe, hiding its exit code. Consequently, the test could continue even if 'git merge' exited with error. Use an intermediate file between 'git merge' and 'test_i18ngrep' to catch a

Re: [RFC PATCH 000/194] Moving global state into the repository object

On Mon, Feb 5, 2018 at 3:51 PM, Stefan Beller wrote: > This series moves a lot of global state into the repository struct. > It applies on top of 2512f15446149235156528dafbe75930c712b29e (2.16.0) > It can be found at https://github.com/stefanbeller/git/tree/object-store > >

Re: Fetch-hooks

Leo Gaspard wrote: > That said, I just came upon [1] (esp. the description [2] and the patch > [3]), and wondered: it looks like the patch was abandoned midway in > favor of a hook refactoring. Would you happen to know whether the hook > refactoring eventually took place, and/or whether this patch

How to produce a loose ref+size explosion via pruning + git-gc

I'll probably submit docs for this eventually, but the docs in my --prune-tags series were already hard enough to review. Try running this ( rm -rf /tmp/git && git clone https://github.com/git/git /tmp/git && cd /tmp/git >/dev/null && du -sh .git && git

Re: Automatic parameters completion

On Thu, Feb 8, 2018 at 9:03 AM, Andrzej wrote: > I have Linux Mint and its terminal besides usual completion (add file name > when type first letter and press tab) also can complete git parameters. How > is doing this? Bash knows git or bash has special interface to

Automatic parameters completion

I have Linux Mint and its terminal besides usual completion (add file name when type first letter and press tab) also can complete git parameters. How is doing this? Bash knows git or bash has special interface to completion and git uses it? I want in my Linux program apply this mechanism.

Re: Bug Report: Subtrees and GPG Signed Commits

On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano wrote: > Given that all references to this shell function seem to do > > sometree=$(toptree_for_commit $something) > > and then $sometree is used as if it were a tree object name, I can > understand why the lack of

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Junio, On Wed, 7 Feb 2018, Junio C Hamano wrote: > Øyvind Rønningstad writes: > > >> So no, I do not think that --recreate-merges --first-parent is a good > > idea > >> at all. Unless you try to do that non-interactively only, *and > > disallow it > >> in interactive

Re: [PATCH v2 00/41] Automate updating git-completion.bash a bit

On Thu, Feb 8, 2018 at 2:23 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> I posted a proof of concept a while back [1]. This is the full version. >> >> This series lets "git" binary help git-completion.bash to complete >> -- so that when a

Re: Unexpected git diff output during merge conflict

Ah, the whitespace that was added to enable the >>> markers to be added... that makes sense. Which means the output is correct and some assumptions my code makes about the format of the Combined Diff are wrong. Thanks! Nick On 8 February 2018 at 11:25, Jeff King wrote: > On

Re: "git branch" issue in 2.16.1

> On 08 Feb 2018, at 12:13, Lars Schneider wrote: > > >> On 08 Feb 2018, at 09:50, Jeff King wrote: >> >> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote: >> 1. You have $LESS in your environment (without "F") on one platform

Re: Unexpected git diff output during merge conflict

On Thu, Feb 08, 2018 at 10:51:57AM +, Nick O'Leary wrote: > $ git diff README.md > diff --cc README.md > index 61d78b2,620d806..000 > --- a/README.md > +++ b/README.md > @@@ -1,7 -1,1 +1,11 @@@ > -This is my default readme > ++<<< HEAD > +merged-history-test > +===

Re: "git branch" issue in 2.16.1

> On 08 Feb 2018, at 09:50, Jeff King wrote: > > On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote: > >>> 1. You have $LESS in your environment (without "F") on one platform >>>but not the other. >> >> I think that's it. On my system LESS is defined to "-R". >>

Unexpected git diff output during merge conflict

Hi, I have a merge conflict on a file and the git diff output looks wrong to me. Here's how to recreate: On branch 'dev' add/commit a file (called README.md) with the contents ( '--' used to delimit the file, not included in the content): --- This is my default readme --- On

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

On Mon, Feb 05, 2018 at 02:56:19PM -0500, Ben Peart wrote: > diff --git a/dir.c b/dir.c > index 7c4b45e30e..da93374f0c 100644 > --- a/dir.c > +++ b/dir.c > @@ -2297,7 +2297,8 @@ int read_directory(struct dir_struct *dir, struct > index_state *istate, >

Re: "git branch" issue in 2.16.1

On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote: > > 1. You have $LESS in your environment (without "F") on one platform > > but not the other. > > I think that's it. On my system LESS is defined to "-R". > > This opens the pager: > > $ echo "TEST" | less > > This

Re: [PATCHv4] tag: add --edit option

Please ignore ! v3 with the nits fixed was picked by Junio Le 07/02/2018 à 17:55, Nicolas Morey-Chaisemartin a écrit : > Add a --edit option whichs allows modifying the messages provided by -m or -F, > the same way git commit --edit does. > > Signed-off-by: Nicolas Morey-Chaisemartin

Re: [PATCH] send-email: error out when relogin delay is missing

On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote: > [...] > Error out for now instead of potentially confusing the user. > As 5453b83bdf (send-email: --batch-size to work around some SMTP > server limit, 2017-05-21) lays out, we rather want to not have this > interface

<    1   2