[PATCH 1/1] Mark messages for translations

Small changes in messages to fit the style and typography of rest Reuse already translated messages if possible Do not translate messages aimed at developers of git Fix unit tests depending on the original string Use `test_i18ngrep` for tests with translatable strings Change and verifyrest of

[PATCH 0/1] Mark messages for translations

Hi all, Continuing with ths suggestions for improvements. Racap since last time: Eric Sunshine: 1. Use 'test_i18ngrep' rather than 'grep' Jeff King: 2. Fix t1506 Previous changes: Johannes Sixt: 1. Lower-case letters at the beginning of error messages 2. Past tense to present tense

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

Am 09.02.2018 um 07:11 schrieb Sergey Organov: Johannes Schindelin writes: Let me explain the scenario which comes up plenty of times in my work with Git for Windows. We have a thicket of some 70 branches on top of git.git's latest release. These branches often

Re: [PATCH v2 17/17] fetch: make the --fetch-prune work with

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > fetch: make the --fetch-prune work with Do you mean s/--fetch-prune/--prune-tags/ ? > Make the new --prune-tags option work properly when git-fetch is > invoked with a parameter instead of a > parameter. > >

Re: [PATCH v2 16/17] fetch: add a --fetch-prune option and fetch.pruneTags config

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > Add a --fetch-prune option to git-fetch, along with fetch.pruneTags > config option. [...] > > Signed-off-by: Ævar Arnfjörð Bjarmason > --- > diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh >

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

Johannes Schindelin writes: [...] > With this patch, the goodness of the Git garden shears comes to `git > rebase -i` itself. Passing the `--recreate-merges` option will generate > a todo list that can be understood readily, and where it is obvious > how to reorder

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

Hi, Johannes Schindelin writes: > On Wed, 7 Feb 2018, Sergey Organov wrote: >> Johannes Schindelin writes: >> > +--recreate-merges:: >> > + Recreate merge commits instead of flattening the history by replaying >> > + merges. Merge

Re: [PATCH v2] name-hash: properly fold directory names in adjust_dirname_case()

On Thu, Feb 08, 2018 at 02:23:33PM -0500, Ben Peart wrote: [] > - > +test_expect_success CASE_INSENSITIVE_FS 'add directory (with different > case)' ' > + git reset --hard initial && > + mkdir -p dir1/dir2 && > + echo > dir1/dir2/a && > + echo > dir1/dir2/b && Thanks for

Re: [PATCH v2 13/17] git remote doc: correct dangerous lies about what prune does

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > The "git remote prune " command uses the same machinery as "git > fetch --prune", and shares all the same caveats, but its > documentation has suggested that it'll just "delete stale > remote-tracking branches

Re: [PATCH v2 12/17] git fetch doc: add a new section to explain the ins & outs of pruning

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > Add a new section to canonically explain how remote reference pruning > works, and how users should be careful about using it in conjunction > with tag refspecs in particular. > [...] > Signed-off-by: Ævar

Re: [PATCH v2 11/17] fetch tests: fetch as well as fetch []

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > When a remote URL is supplied on the command-line the internals of the > fetch are different, in particular the code in get_ref_map(). An > earlier version of the subsequent fetch.pruneTags patch hid a segfault >

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

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > 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

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

On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason wrote: > 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. > [...] > Signed-off-by: Ævar Arnfjörð Bjarmason

Re: [PATCH 3/3] t1404: use 'test_must_fail stderr='

On Fri, Feb 9, 2018 at 4:16 AM, Eric Sunshine wrote: > On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote: >> Instead of 'test_must_fail git cmd... 2>output.err', which redirects >> the standard error of the 'test_must_fail' helper function as well,

Re: [PATCH 3/3] t1404: use 'test_must_fail stderr='

On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote: > Instead of 'test_must_fail git cmd... 2>output.err', which redirects > the standard error of the 'test_must_fail' helper function as well, > causing various issues as discussed in the previous patch. ECANTPARSE: This

Re: [PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote: > To check that a git command fails and to inspect its error message we > usually execute a command like this throughout our test suite: > > test_must_fail git command --option 2>output.err > > Note that this command

[PATCH 1/3] t: document 'test_must_fail ok='

Since 'test_might_fail' is implemented as a thin wrapper around 'test_must_fail', it also accepts the same options. Mention this in the docs as well. Signed-off-by: SZEDER Gábor --- t/README| 14 -- t/test-lib-functions.sh | 10 ++ 2

[PATCH 0/3] Teach 'test_must_fail' to save the command's stderr to a file

To check that a git command fails with the expected error message, we usually execute a command like this: test_must_fail git command --option 2>output.err Alas, this command doesn't limit the redirection to the git command, but it redirects the standard error of the

[PATCH 3/3] t1404: use 'test_must_fail stderr='

Instead of 'test_must_fail git cmd... 2>output.err', which redirects the standard error of the 'test_must_fail' helper function as well, causing various issues as discussed in the previous patch. With this patch t1404 succeeds when run with '-x', even with shells not supporting $BASH_XTRACEFD.

[PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

To check that a git command fails and to inspect its error message we usually execute a command like this throughout our test suite: test_must_fail git command --option 2>output.err Note that this command doesn't limit the redirection to the git command, but it redirects the standard error of

Re: bad behaviour while using git rebase -i -p

Jan Viktorin writes: > since Git 2.16.1, I've noticed a bad behaviour of git rebase -i -p. It > screws up merge commits created with --log (or config merge.log = true) > in my history. A good merge commit with message like: > > Merge branch 'test' > > *

I await your response for more close discussions.

Hello dear , I am Mr. Jeremiah Bworo , nationality of Ethiopia but currently In Benin Republic as a Principal Director with Federal Ministry Of Works and Housing here . I will be delighted to invest with you there in your country into lucrative investments under your management as far as you

bad behaviour while using git rebase -i -p

Hello, since Git 2.16.1, I've noticed a bad behaviour of git rebase -i -p. It screws up merge commits created with --log (or config merge.log = true) in my history. A good merge commit with message like: Merge branch 'test' * test: c b is changed after rebase (without

Re: [PATCH v3 06/14] commit-graph: implement 'git-commit-graph read'

Derrick Stolee writes: > +'read':: > + > +Read a graph file given by the graph-head file and output basic > +details about the graph file. "a graph file", assuming that there must be only one in the specified place? Or if there are more than one, read all of them? Or is it an

Re: [PATCH v3 03/14] commit-graph: create git-commit-graph builtin

Derrick Stolee writes: > I wanted to have the smallest footprint as possible in the objects > directory, and the .git/objects directory currently only holds > folders. When we cull stale files from pack directory, we rely on the related files to share pack-.* pattern. It is

Re: [PATCH v3 01/14] commit-graph: add format document

Derrick Stolee writes: > You're right that this data is redundant. It is easy to describe the > width of the tables using the OID length, so it is convenient to have > that part of the format. Also, it is good to have 4-byte alignment > here, so we are not wasting space. > >

Re: [PATCH] CodingGuidelines: mention "static" and "extern"

On Thu, Feb 8, 2018 at 4:38 PM, Jeff King wrote: > Subject: [PATCH] CodingGuidelines: mention "static" and "extern" > [...] > > Signed-off-by: Jeff King > --- > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines > @@ -386,6 +386,11 @@ For C

Re: [PATCH] rebase -p: fix incorrect commit message when calling `git merge`.

gregory.herr...@oracle.com writes: > Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git > merge`"), commit message of the merge commit being rebased is passed to > the merge command using a subshell executing 'git rev-parse --sq-quote'. > > Double quotes are needed around this

Re: [PATCH] color.h: document and modernize header

On Thu, Feb 08, 2018 at 05:26:33PM -0500, Eric Sunshine wrote: > > I think the point is that "var" is a quad-state variable (yes, no, auto, > > or "unknown") and we are converting to a boolean. This would probably be > > a lot more clear if GIT_COLOR_* were all enum values and not #defines, > >

Re: [PATCH] color.h: document and modernize header

On Thu, Feb 8, 2018 at 3:43 PM, Jeff King wrote: > On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote: >> +/* >> + * Resolve the constants as returned by git_config_colorbool() >> + * (specifically "auto") to a boolean answer. >> + */ >> +extern int want_color(int var);

Re: Fetch-hooks

On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> Hmm, OK, so I guess I'll try to update the patch when I get some time to >> delve into git's internals, as my use case (forbidding some fetches) >> couldn't afaik be covered by a wrapper hook. > > Per my reading of >

Re: Left-over COMMIT_EDITMSG file in gitdir

Linus Torvalds writes: > In that rewrite, removing some temporary files seems to have been left > out. At least one: .git/COMMIT_EDITMSG. > > In the original commit.sh shell script, we can find this: > > rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG"

Re: [PATCH v3 04/14] commit-graph: implement write_commit_graph()

Derrick Stolee writes: > +char* get_commit_graph_filename_hash(const char *pack_dir, Asterisk sticks to the identifier, not type, in our codebase. > + struct object_id *hash) > +{ > + size_t len; > + struct strbuf path = STRBUF_INIT; >

Left-over COMMIT_EDITMSG file in gitdir

This may be intentional, but if so, it's not obvious.. Back long long ago, the original "git commit" shell script got rewritten in C. In that rewrite, removing some temporary files seems to have been left out. At least one: .git/COMMIT_EDITMSG. In the original commit.sh shell script, we can

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

On Thu, Feb 8, 2018 at 1:21 PM, Stefan Beller wrote: > On Thu, Feb 8, 2018 at 12:08 AM, Eric Sunshine > wrote: >> On Wed, Feb 7, 2018 at 6:43 PM, Stefan Beller wrote: >>> +die __("When a batch size is given, the relogin delay

Re: [PATCH] CodingGuidelines: mention "static" and "extern"

On Thu, Feb 8, 2018 at 1:38 PM, Jeff King wrote: > On Thu, Feb 08, 2018 at 01:04:08PM -0800, Stefan Beller wrote: > >> You may sense a pattern here: I currently have the very firm understanding >> we use the extern keyword in our codebase. >> >> And I can also attest that this was

[PATCH] CodingGuidelines: mention "static" and "extern"

On Thu, Feb 08, 2018 at 01:04:08PM -0800, Stefan Beller wrote: > You may sense a pattern here: I currently have the very firm understanding > we use the extern keyword in our codebase. > > And I can also attest that this was not always the case, as back in the > day I remember writing patches

Re: [PATCH v3 03/14] commit-graph: create git-commit-graph builtin

On 2/8/2018 4:27 PM, Junio C Hamano wrote: Derrick Stolee writes: Teach git the 'commit-graph' builtin that will be used for writing and reading packed graph files. The current implementation is mostly empty, except for a '--pack-dir' option. Why do we want to use "pack"

Re: [PATCH v3 01/14] commit-graph: add format document

On 2/8/2018 4:21 PM, Junio C Hamano wrote: Derrick Stolee writes: Add document specifying the binary format for commit graphs. This format allows for: * New versions. * New hash functions and hash lengths. It still is unclear, at least to me, why OID and OID length are

Re: [PATCH v3 03/14] commit-graph: create git-commit-graph builtin

Derrick Stolee writes: > Teach git the 'commit-graph' builtin that will be used for writing and > reading packed graph files. The current implementation is mostly > empty, except for a '--pack-dir' option. Why do we want to use "pack" dir, when this is specifically designed

Re: [PATCH v3 01/14] commit-graph: add format document

Derrick Stolee writes: > Add document specifying the binary format for commit graphs. This > format allows for: > > * New versions. > * New hash functions and hash lengths. It still is unclear, at least to me, why OID and OID length are stored as if they can be independent.

Re: [PATCHv3 2/4] builtin/blame: dim uninteresting metadata

On Mon, Jan 8, 2018 at 11:34 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> +color.blame.repeatedMeta:: >> + Use the customized color for the part of git-blame output that >> + is repeated meta information per line (such as commit id, >> +

Re: Fetch-hooks

On Thu, Feb 08 2018, Leo Gaspard jotted: > On 02/08/2018 04:30 PM, Joey Hess wrote: >> 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

Re: [PATCH] color.h: document and modernize header

On Thu, Feb 8, 2018 at 12:43 PM, Jeff King wrote: > On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote: > >> int color_fprintf(FILE *fp, const char *color, const char *fmt, ...) >> { >> va_list args; >> diff --git a/color.h b/color.h >> index

[PATCH] rebase -p: fix incorrect commit message when calling `git merge`.

From: Gregory Herrero Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git merge`"), commit message of the merge commit being rebased is passed to the merge command using a subshell executing 'git rev-parse --sq-quote'. Double quotes are needed around

Re: [PATCH] color.h: document and modernize header

On Thu, Feb 08, 2018 at 12:15:46PM -0800, Stefan Beller wrote: > int color_fprintf(FILE *fp, const char *color, const char *fmt, ...) > { > va_list args; > diff --git a/color.h b/color.h > index fd2b688dfb..8c7e6c41c2 100644 > --- a/color.h > +++ b/color.h > @@ -72,26 +72,50 @@ extern int

[PATCH v3 09/14] commit-graph: implement --delete-expired

Teach git-commit-graph to delete the graph files in the pack directory that were not referenced by 'graph_head' during this process. This cleans up space for the user while not causing race conditions with other running Git processes that may be referencing the previous graph file. To delete old

[PATCH v3 13/14] commit-graph: read only from specific pack-indexes

Teach git-commit-graph to inspect the objects only in a certain list of pack-indexes within the given pack directory. This allows updating the commit graph iteratively, since we add all commits stored in a previous commit graph. Signed-off-by: Derrick Stolee ---

[PATCH v3 02/14] graph: add commit graph design document

Add Documentation/technical/commit-graph.txt with details of the planned commit graph feature, including future plans. Signed-off-by: Derrick Stolee --- Documentation/technical/commit-graph.txt | 189 +++ 1 file changed, 189 insertions(+)

[PATCH v3 06/14] commit-graph: implement 'git-commit-graph read'

Teach git-commit-graph to read commit graph files and summarize their contents. Use the read subcommand to verify the contents of a commit graph file in the tests. Signed-off-by: Derrick Stolee --- Documentation/git-commit-graph.txt | 16 builtin/commit-graph.c

[PATCH v3 14/14] commit-graph: build graph from starting commits

Teach git-commit-graph to read commits from stdin when the --stdin-commits flag is specified. Commits reachable from these commits are added to the graph. This is a much faster way to construct the graph than inspecting all packed objects, but is restricted to known tips. For the Linux

[PATCH v3 04/14] commit-graph: implement write_commit_graph()

Teach Git to write a commit graph file by checking all packed objects to see if they are commits, then store the file in the given pack directory. Signed-off-by: Derrick Stolee --- Makefile | 1 + commit-graph.c | 368

[PATCH v3 05/14] commit-graph: implement 'git-commit-graph write'

Teach git-commit-graph to write graph files. Create new test script to verify this command succeeds without failure. Signed-off-by: Derrick Stolee --- Documentation/git-commit-graph.txt | 39 + builtin/commit-graph.c | 43 +++

[PATCH v3 10/14] commit-graph: add core.commitGraph setting

The commit graph feature is controlled by the new core.commitGraph config setting. This defaults to 0, so the feature is opt-in. The intention of core.commitGraph is that a user can always stop checking for or parsing commit graph files if core.commitGraph=0. Signed-off-by: Derrick Stolee

[PATCH v3 08/14] commit-graph: implement 'git-commit-graph clear'

Teach Git to delete the current 'graph_head' file and the commit graph it references. This is a good safety valve if somehow the file is corrupted and needs to be recalculated. Since the commit graph is a summary of contents already in the ODB, it can be regenerated. Signed-off-by: Derrick Stolee

[PATCH v3 07/14] commit-graph: update graph-head during write

It is possible to have multiple commit graph files in a pack directory, but only one is important at a time. Use a 'graph_head' file to point to the important file. Teach git-commit-graph to write 'graph_head' upon writing a new commit graph file. Signed-off-by: Derrick Stolee

[PATCH v3 12/14] commit-graph: close under reachability

Teach write_commit_graph() to walk all parents from the commits discovered in packfiles. This prevents gaps given by loose objects or previously-missed packfiles. Also automatically add commits from the existing graph file, if it exists. Signed-off-by: Derrick Stolee ---

[PATCH v3 11/14] commit: integrate commit graph with commit parsing

Teach Git to inspect a commit graph file to supply the contents of a struct commit when calling parse_commit_gently(). This implementation satisfies all post-conditions on the struct commit, including loading parents, the root tree, and the commit date. The only loosely-expected condition is that

[PATCH v3 03/14] commit-graph: create git-commit-graph builtin

Teach git the 'commit-graph' builtin that will be used for writing and reading packed graph files. The current implementation is mostly empty, except for a '--pack-dir' option. Signed-off-by: Derrick Stolee --- .gitignore | 1 +

[PATCH v3 00/14] Serialized Git Commit Graph

Thanks to everyone who gave comments on v1 and v2. Hopefully the following points have been addressed: * Fixed inter-commit problems where certain fixes did not arrive until later commits. * Converted from submode flags ("git commit-graph --write") to subcommands ("git commit-graph write").

[PATCH v3 01/14] commit-graph: add format document

Add document specifying the binary format for commit graphs. This format allows for: * New versions. * New hash functions and hash lengths. * Optional extensions. Basic header information is followed by a binary table of contents into "chunks" that include: * An ordered list of commit object

Re: [PATCH] docs/interpret-trailers: fix agreement error

Jonathan Tan writes: > On Thu, 8 Feb 2018 02:56:14 + > "brian m. carlson" wrote: > >> Existing trailers are extracted from the input message by looking for >> -a group of one or more lines that (i) are all trailers, or (ii) contains

[PATCH] color.h: document and modernize header

Add documentation explaining the functions in color.h. While at it, mark them extern and migrate the function `color_set` into grep.c, where the only callers are. Signed-off-by: Stefan Beller --- This used to be part of sb/blame-color, but I realized this is not strictly

Re: [PATCH v2 00/17] document & test fetch pruning & add fetch.pruneTags

Ævar Arnfjörð Bjarmason writes: > On Thu, Feb 08 2018, Ævar Arnfjörð Bjarmason jotted: > >> As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I >> noticed in v3 where it would segfault on some git-fetch invocations, >> but there were not tests anywhere that

[PATCH v2] name-hash: properly fold directory names in adjust_dirname_case()

Correct the pointer arithmetic in adjust_dirname_case() so that it calls find_dir_entry() with the correct string length. Previously passing in "dir1/foo" would pass a length of 6 instead of the correct 4. This resulted in find_dir_entry() never finding the entry and so the subsequent memcpy

Netgear X8 R8500

Hello, I’m very beginner and literally a grandma. Would like Tomatoes for my Netgear X8 R8500 router. Very misleading netgear product saying OpenVPN and had no idea about client or I would have to do all this stuff and the netgear security vulnerabilities are horrid. Was told to shut it down. I

Re: [PATCH 2/2] always check for NULL return from packet_read_line()

On Thu, Feb 08, 2018 at 01:47:50PM -0500, Jon Simons wrote: > The packet_read_line() function will die if it sees any > protocol or socket errors. But it will return NULL for a > flush packet; some callers which are not expecting this may > dereference NULL if they get an unexpected flush. This

[PATCH 1/2] correct error messages for NULL packet_read_line()

From: Jeff King The packet_read_line() function dies if it gets an unexpected EOF. It only returns NULL if we get a flush packet (or technically, a zero-length "0004" packet, but nobody is supposed to send those, and they are indistinguishable from a flush in this interface).

[PATCH 2/2] always check for NULL return from packet_read_line()

The packet_read_line() function will die if it sees any protocol or socket errors. But it will return NULL for a flush packet; some callers which are not expecting this may dereference NULL if they get an unexpected flush. This would involve the other side breaking protocol, but we should flag the

[PATCH 0/2] Fix NULL checks for some packet_read_line call sites

Included here are a couple of fixes and cleanups for handling NULL return values from 'packet_read_line'. Jeff King (1): correct error messages for NULL packet_read_line() Jon Simons (1): always check for NULL return from packet_read_line() builtin/archive.c | 2 +- fetch-pack.c | 4

Hello Dear Friend,

Hello Dear Friend, Greetings and how are you doing? I want to know if you are kind to be my partner in claiming the fund of $13.6 MillionUSD left by a late client. If you're interested please Revert for more details. You can visit the web for more details.

Re: [PATCH v1] name-hash: properly fold directory names in adjust_dirname_case()

Torsten Bögershausen writes: > My personal favorite would be to spell out what we expect and run a diff. > When it fails, we can see what fails, and the function would look > like this: I'd rather not to have the "sort" there; output from ls-files is meant to be stable; passing

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

On Thu, Feb 8, 2018 at 12:08 AM, Eric Sunshine wrote: > 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

Re: [PATCH v2 00/17] document & test fetch pruning & add fetch.pruneTags

On Thu, Feb 08 2018, Ævar Arnfjörð Bjarmason jotted: > As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I > noticed in v3 where it would segfault on some git-fetch invocations, > but there were not tests anywhere that caught that. ...and of course this whole submission this

Re: [PATCH v1] name-hash: properly fold directory names in adjust_dirname_case()

Ben Peart writes: > Correct the pointer arithmetic in adjust_dirname_case() so that it calls > find_dir_entry() with the correct string length. Previously passing in > "dir1/foo" would pass a length of 6 instead of the correct 4. This resulted > in > find_dir_entry()

Re: [PATCH] docs/interpret-trailers: fix agreement error

On Thu, 8 Feb 2018 02:56:14 + "brian m. carlson" wrote: > Existing trailers are extracted from the input message by looking for > -a group of one or more lines that (i) are all trailers, or (ii) contains at > -least one Git-generated or user-configured trailer

Re: [PATCH v1] name-hash: properly fold directory names in adjust_dirname_case()

On 2/8/2018 12:21 PM, Torsten Bögershausen wrote: On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote: [] diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index b29d749bb7..219c96594c 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -80,7 +80,17 @@

Re: [PATCH v1] name-hash: properly fold directory names in adjust_dirname_case()

On Wed, Feb 07, 2018 at 07:41:56PM -0500, Ben Peart wrote: [] > diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh > index b29d749bb7..219c96594c 100755 > --- a/t/t0050-filesystem.sh > +++ b/t/t0050-filesystem.sh > @@ -80,7 +80,17 @@ test_expect_success 'merge (case change)' ' > git

Re: Fetch-hooks

On 02/08/2018 04:30 PM, Joey Hess wrote: > 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

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

On Thu, Feb 08, 2018 at 04:56:47PM +0100, SZEDER Gábor wrote: > 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'

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

On Thu, Feb 08, 2018 at 04:56:55PM +0100, SZEDER Gábor wrote: > Prevent similar mistakes in the future by validating 'test_i18ngrep's > parameters requiring that > > - The last parameter names an existing file to be read, effectively > forbiding piping into 'test_i18ngrep'.

Re: "git branch" issue in 2.16.1

> On 08 Feb 2018, at 17:19, Kevin Daudt wrote: > > On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote: >> >>> On 08 Feb 2018, at 12:13, Lars Schneider wrote: >>> >>> On 08 Feb 2018, at 09:50, Jeff King wrote:

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

On Thu, Jan 11 2018, Ævar Arnfjörð Bjarmason jotted: > I recently disabled gc.auto=0 and my nightly aggressive repack script on > our big monorepo across our infra, relying instead on git gc --auto in > the background to just do its thing. > > I didn't want users to wait for git-gc, and I'd

[PATCH v2 06/17] fetch tests: re-arrange arguments for future readability

Re-arrange the arguments to the test_configured_prune() function used in this test to pass the arguments to --fetch last. A subsequent change will test for more elaborate fetch arguments, including long refspecs. It'll be more readable to be able to wrap those on a new line of their own.

[PATCH v2 04/17] remote: add a macro for "refs/tags/*:refs/tags/*"

Add a macro with the refspec string "refs/tags/*:refs/tags/*". There's been a pre-defined struct version of this since e0aaa29ff3 ("Have a constant extern refspec for "--tags"", 2008-04-17), but nothing that could be passed to e.g. add_fetch_refspec(). This will be used in subsequent commits to

[PATCH v2 08/17] fetch tests: test --prune and refspec interaction

Add a test for the interaction between explicitly provided refspecs and fetch.prune. There's no point in adding this boilerplate to every combination of unset/false/true, it's instructive and sufficient to show that no matter if the variable is unset, false or true the refspec on the command-line

[PATCH v2 09/17] fetch tests: double quote a variable for interpolation

If the $cmdline variable contains arguments with spaces they won't be interpolated correctly, since the body of the test is single quoted, and because test-lib.sh does its own eval(). This will be used in a subsequent commit to pass arguments that need to be quoted to git-fetch, i.e. a file://

[PATCH v2 10/17] fetch tests: expand case/esac for later change

Expand a compact case/esac statement for a later change that'll add more logic to the body of the "*" case. This is a whitespace-only change. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH v2 15/17] fetch tests: add scaffolding for the new fetch.pruneTags

The fetch.pruneTags configuration doesn't exist yet, but will be added in a subsequent commit. Since testing for it requires adding new parameters to the test_configured_prune function it's easier to review this patch first to assert that no functional changes are introduced yet. Signed-off-by:

[PATCH v2 11/17] fetch tests: fetch as well as fetch []

When a remote URL is supplied on the command-line the internals of the fetch are different, in particular the code in get_ref_map(). An earlier version of the subsequent fetch.pruneTags patch hid a segfault because the difference wasn't tested for. Now all the tests are run as both of the

[PATCH v2 12/17] git fetch doc: add a new section to explain the ins & outs of pruning

Add a new section to canonically explain how remote reference pruning works, and how users should be careful about using it in conjunction with tag refspecs in particular. A subsequent commit will update the git-remote documentation to refer to this section, and details the motivation for writing

[PATCH v2 13/17] git remote doc: correct dangerous lies about what prune does

The "git remote prune " command uses the same machinery as "git fetch --prune", and shares all the same caveats, but its documentation has suggested that it'll just "delete stale remote-tracking branches under ". This isn't true, and hasn't been true since at least v1.8.5.6 (the oldest version I

[PATCH v2 14/17] git-fetch & config doc: link to the new PRUNING section

Amend the documentation for fetch.prune, fetch..prune and --prune to link to the recently added PRUNING section. I'd have liked to link directly to it with "<>" from fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt also includes it, but doesn't include that option). However

[PATCH v2 17/17] fetch: make the --fetch-prune work with

Make the new --prune-tags option work properly when git-fetch is invoked with a parameter instead of a parameter. This change is split off from the introduction of --prune-tags due to the relative complexity of munging the incoming argv, which is easier to review as a separate change.

[PATCH v2 16/17] fetch: add a --fetch-prune option and fetch.pruneTags config

Add a --fetch-prune option to git-fetch, along with fetch.pruneTags config option. This allows for doing any of: git fetch -p -P git fetch --prune --prune-tags git fetch -p -P origin git fetch --prune --prune-tags origin Or simply: git config fetch.prune true && git

[PATCH v2 05/17] fetch tests: refactor in preparation for testing tag pruning

In a subsequent commit this function will learn to test for tag pruning, prepare for that by making space for more variables, and making it clear that "expected" here refers to branches. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 9 ++--- 1 file changed,

[PATCH v2 03/17] fetch: stop accessing "remote" variable indirectly

Access the "remote" variable passed to the fetch_one() directly rather than through the gtransport wrapper struct constructed in this function for other purposes. This makes the code more readable, as it's now obvious that the remote struct doesn't somehow get munged by the prepare_transport()

Re: "git branch" issue in 2.16.1

On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote: > > > 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: >

[PATCH v2 07/17] fetch tests: add a tag to be deleted to the pruning tests

Add a tag to be deleted to the fetch --prune tests. The tag is always kept for now, which is the expected behavior, but now I can add a test for tag pruning in a later commit. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 93

[PATCH v2 00/17] document & test fetch pruning & add fetch.pruneTags

As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I noticed in v3 where it would segfault on some git-fetch invocations, but there were not tests anywhere that caught that. So in addition to fixing that issue, this fleshens out the testing being set up as part of this series so

  1   2   >