Draft of Git Rev News edition 33

Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub

Add feature to stop tracking files while keeping them in the index

Hello everyone, Currently, a file can be either tracked or untracked. So, I propose we add a feature to stop tracking files while keeping them in the index. Example scenario: - A developer would like to add some configuration files with example values, e.g. DB_PASSWORD=changeme. But in the

[PATCH] git-send-email: fix --cc-cmd get_maintainer.pl regression

Since the removal of Mail::Address from git-send-email certain address patterns returned by common get_maintainer.pl scripts now fail to get correctly parsed by the built-in Git::parse_mailboxes. Specifically the patterns with embedded parenthesis fail. For example from the Linux kernel

[PATCH v2] git-send-email: fix --cc-cmd get_maintainer.pl regression

Since the removal of Mail::Address from git-send-email certain address patterns returned by common get_maintainer.pl scripts now fail to get correctly parsed by the built-in Git::parse_mailboxes. Specifically the patterns with embedded parenthesis fail. For example from the Linux kernel

Re: [PATCH V4] config: add --expiry-date

On Sat, Nov 18, 2017 at 12:37:03PM +0900, Junio C Hamano wrote: > > +int git_config_expiry_date(timestamp_t *timestamp, const char *var, const > > char *value) > > +{ > > + if (!value) > > + return config_error_nonbool(var); > > + if (parse_expiry_date(value, timestamp)) > > +

Re: [PATCH] Makefile: check that tcl/tk is installed

On Fri, Nov 17, 2017 at 6:42 PM, Todd Zullinger wrote: > Christian Couder wrote: >> >> On Thu, Nov 16, 2017 at 2:35 AM, Junio C Hamano wrote: >>> >>> I suspect that this change will hurt those who package Git for other >>> people. >> >> >> Maybe a little bit,

Re: [PATCH] Makefile: check that tcl/tk is installed

(Sorry I forgot to mark this as v2.) On Mon, Nov 20, 2017 at 6:15 PM, Christian Couder wrote: > By default running `make install` in the root directory of the > project will set TCLTK_PATH to `wish` and then go into the "git-gui" > and "gitk-git" sub-directories to

[PATCH] Makefile: check that tcl/tk is installed

By default running `make install` in the root directory of the project will set TCLTK_PATH to `wish` and then go into the "git-gui" and "gitk-git" sub-directories to build and install these 2 sub-projects. When Tcl/Tk is not installed, the above will succeed if gettext is installed, as Tcl/Tk is

Re: Add feature to stop tracking files while keeping them in the index

Hi Viet, On 20/11/2017 10:52, Viet Nguyen wrote: > Currently, a file can be either tracked or untracked. So, I propose we > add a feature to stop tracking files while keeping them in the index. > > Example scenario: > - A developer would like to add some configuration files with example >

Re: [PATCH v3 5/5] Testing: provide tests requiring them with ellipses after SHA-1 values

From: "Junio C Hamano" Ann T Ropea writes: *1* We are being overly generous in t4013-diff-various.sh because we do not want to destroy/take apart the here-document. Given that all this a temporary measure, we should get away with it. So, the need to

Re: [PATCH] Makefile: check that tcl/tk is installed

On Fri, Nov 17, 2017 at 11:02 PM, Jeff King wrote: > > I'm actually tempted to say that we should not be building the tcl parts > by default. IOW, instead of NO_TCLTK we should have USE_TCLTK. That > would also require an adjustment by package builders, but it would > hopefully be

Re: [PATCH 6/7] builtin/describe.c: describe a blob

From: "Junio C Hamano" : Friday, November 10, 2017 1:24 AM [catch up] "Philip Oakley" writes: From: "Stefan Beller" Rereading this discussion, there is currently no urgent thing to address? True. Then the state as announced

Re: [PATCH v1 1/4] fastindex: speed up index load through parallelization

On Mon, Nov 20, 2017 at 09:20:35AM -0500, Jeff King wrote: > Out of curiosity, have you tried experimenting with any high-performance > 3rd-party allocator libraries? I've often wondered if we could get a > performance improvement from dropping in a new allocator, but was never > able to measure

Re: [PATCH 1/6] t4051: add test for comments preceding function lines

Am 20.11.2017 um 01:36 schrieb Junio C Hamano: > René Scharfe writes: > >> your suggested full-comment metric, i.e. more than nothing. But more >> importantly it's the actual comment payload. The leading "/*" line is >> included as a consequence of the employed heuristic, but a

Re: [PATCH v4 07/10] introduce fetch-object: fetch one promisor object

On 11/17/2017 3:17 PM, Stefan Beller wrote: On Fri, Nov 17, 2017 at 11:49 AM, Jeff Hostetler wrote: On 11/16/2017 2:57 PM, Ramsay Jones wrote: On 16/11/17 18:12, Jeff Hostetler wrote: From: Jonathan Tan Introduce fetch-object,

Re: [PATCHv5 7/7] builtin/describe.c: describe a blob

From: "Stefan Beller" Sent: Thursday, November 16, 2017 2:00 AM [in catch up mode..] Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) When describing commits, we

Re: [PATCH 6/7] builtin/describe.c: describe a blob

From: "Philip Oakley" s/with/without/ ... From: "Junio C Hamano" : Friday, November 10, 2017 1:24 AM [catch up] "Philip Oakley" writes: From: "Stefan Beller" Rereading this discussion, there is

[RFC PATCH v2 2/2] bisect: add "edit" command

Add an "edit" command to git bisect, which will save the current bisection log to a file, open an editor to allow the user to replay the bisection log, then replay the edited log file. This can already be done as separate steps, and doing so is described in the bisect documentation; this commit

[RFC PATCH v2 0/2] bisect: add a single command for editing logs

When I'm bisecting, I sometimes want to edit the bisection log, e.g. to remove the "skip" marker by a commit I've now found a way to avoid skipping. Rather than requiring users to save off the log, edit it, then replay the edited log as separate commands, this patch series adds support for a "git

[RFC PATCH v2 1/2] bisect: split out replay file parsing

In order to allow a git bisect log file to be replayed without using all the surrounding code to do things like clean the repository state, split out the file-parsing part of bisect_replay into a separate function. Signed-off-by: Adam Dinwoodie --- git-bisect.sh | 9

Re: [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Nov 20 2017, Ævar Arnfjörð Bjarmason jotted: > On Sun, Nov 19 2017, Dan Jacques jotted: > >> [...] > > Firstly the promise of this is very neat. I'm happy to offer any help I > can give. > >> Enable Git to resolve its own binary location using a variety of >> OS-specific and generic

[PATCH v2 23/33] merge-recursive: add a new hashmap for storing file collisions

Directory renames with the ability to merge directories opens up the possibility of add/add/add/.../add conflicts, if each of the N directories being merged into one target directory all had a file with the same name. We need a way to check for and report on such collisions; this hashmap will be

[PATCH v2 20/33] merge-recursive: add a new hashmap for storing directory renames

This just adds dir_rename_entry and the associated functions; code using these will be added in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 35 +++ merge-recursive.h | 8 2 files changed, 43 insertions(+)

[PATCH v2 05/33] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 137 1 file changed, 137 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index d8ead7c56b..335aa1c145 100755 ---

[PATCH v2 27/33] merge-recursive: apply necessary modifications for directory renames

This commit hooks together all the directory rename logic by making the necessary changes to the rename struct, it's dst_entry, and the diff_filepair under consideration. Signed-off-by: Elijah Newren --- merge-recursive.c | 187

[PATCH v2 19/33] merge-recursive: split out code for determining diff_filepairs

Create a new function, get_diffpairs() to compute the diff_filepairs between two trees. While these are currently only used in get_renames(), I want them to be available to some new functions. No actual logic changes yet. Signed-off-by: Elijah Newren --- merge-recursive.c |

[PATCH v2 13/33] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 9e00a26c69..7408c788fc 100755 ---

[PATCH v2 12/33] directory rename detection: miscellaneous testcases to complete coverage

I came up with the testcases in the first eight sections before coding up the implementation. The testcases in this section were mostly ones I thought of while coding/debugging, and which I was too lazy to insert into the previous sections because I didn't want to re-label with all the testcase

[PATCH v2 16/33] merge-recursive: introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH v2 32/33] merge-recursive: avoid spurious rename/rename conflict from dir renames

If a file on one side of history was renamed, and merely modified on the other side, then applying a directory rename to the modified side gives us a rename/rename(1to2) conflict. We should only apply directory renames to pairs representing either adds or renames. Making this change means that a

[PATCH v2 21/33] merge-recursive: add get_directory_renames()

This populates a list of directory renames for us. The list of directory renames is not yet used, but will be in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 149 ++ 1 file changed, 149

[PATCH v2 10/33] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 5db2986de8..2c57a02c6d 100755 ---

[PATCH v2 02/33] merge-recursive: fix logic ordering issue

merge_trees() did a variety of work, including: * Calling get_unmerged() to get unmerged entries * Calling record_df_conflict_files() with all unmerged entries to do some work to ensure we could handle D/F conflicts correctly * Calling get_renames() to check for renames. An easily

[RFC PATCH v2 3/9] merge-recursive: new function for better colliding conflict resolutions

There are three conflict types that represent two (possibly entirely unrelated) files colliding at the same location: * add/add * rename/add * rename/rename(2to1) These three conflict types already share more similarity than might be immediately apparent from their description: (1) the

[RFC PATCH v2 1/9] diffcore-rename: no point trying to find a match better than exact

diffcore_rename() had some code to avoid having destination paths that already had an exact rename detected from being re-checked for other renames. Source paths, however, were re-checked because we wanted to allow the possibility of detecting copies. But if copy detection isn't turned on, then

[RFC PATCH v2 0/9] Improve merge recursive performance

You probably want to wait to review this series until my rename detection series lands so that I can clean up any more conflicts, but I'm posting this new series in case anyone wants to take an early look. It includes fixes identified by the reviews of my other patch series, and has been rebased

[RFC PATCH v2 2/9] merge-recursive: avoid unnecessary string list lookups

Since we're taking entries from active_cache, which is already in sorted order with same-named entries adjacent, we can skip a lookup. Also, we can just use append instead of insert (avoiding the need to find where to put the new item) and still end up with a sorted list. Signed-off-by: Elijah

Re: [PATCH 4/8] connect: split ssh command line options into separate function

On 11/20, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > On 11/20, Jonathan Nieder wrote: > [long stream of quoted context snipped; please cut down the quoted > text to what you are replying to in the future] > >> @@ -972,16 +1031,13 @@ struct child_process *git_connect(int fd[2],

Re: [PATCH 3/8] connect: split git:// setup into a separate function

On 11/20, Jonathan Nieder wrote: > Brandon Williams wrote: > > On 11/20, Jonathan Nieder wrote: > > >> + /* These underlying connection commands die() if they > >> + * cannot connect. > >> + */ > > > > I know this is really just code motion but maybe we can fix the style of > > the comment

Re: [PATCH] bash completion: Add --autostash and --no-autostash to pull

On Mon, Nov 20, 2017 at 10:07 AM, Albert Astals Cid wrote: > Ideally we should only autocomplete if pull has --rebase since > they only work with it but could not figure out how to do that > and the error message of doing git pull --autostash points out > that you need

Re: [PATCH v1 1/4] fastindex: speed up index load through parallelization

On 20/11/17 14:01, Ben Peart wrote: > Further testing has revealed that switching from the regular heap to a > refactored version of the mem_pool in fast-import.c produces similar gains as > parallelizing do_index_load().  This appears to be a much simpler patch for > similar gains so we will

Bad interaction between git clean, gitignore, and deleted submodules

We have the following situation: 1) A .gitignore file that contains '*.pyc' 2) A repo with a submodule named jinja2 In normal use, clients of our repo have it checked out and run things in it, creating files like jinja2/run.pyc. I deleted the jinja2 submodule (by running `git rm jinja2` and

Re: [PATCH 4/8] connect: split ssh command line options into separate function

On 11/20, Jonathan Nieder wrote: > The git_connect function is growing long. Split the portion that > discovers an ssh command and options it accepts before the service > name and path to a separate function to make it easier to read. > > No functional change intended. > > Signed-off-by:

[PATCH v2 30/33] merge-recursive: fix remaining directory rename + dirty overwrite cases

Signed-off-by: Elijah Newren --- merge-recursive.c | 26 +++--- t/t6043-merge-rename-directories.sh | 8 2 files changed, 27 insertions(+), 7 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v2 28/33] merge-recursive: avoid clobbering untracked files with directory renames

Signed-off-by: Elijah Newren --- merge-recursive.c | 42 +++-- t/t6043-merge-rename-directories.sh | 6 +++--- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v2 33/33] merge-recursive: ensure we write updates for directory-renamed file

When a file is present in HEAD before the merge and the other side of the merge does not modify that file, we try to avoid re-writing the file and making it stat-dirty. However, when a file is present in HEAD before the merge and was in a directory that was renamed by the other side of the merge,

[PATCH v2 18/33] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Signed-off-by: Elijah Newren ---

[PATCH v2 31/33] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier patch series, but

[PATCH v2 17/33] merge-recursive: fix leaks of allocated renames and diff_filepairs

get_renames() has always zero'ed out diff_queued_diff.nr while only manually free'ing diff_filepairs that did not correspond to renames. Further, it allocated struct renames that were tucked away in the return string_list. Make sure all of these are deallocated when we are done with them.

[PATCH v2 11/33] directory rename detection: testcases exploring possibly suboptimal merges

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 392 1 file changed, 392 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 2c57a02c6d..b153468a5c 100755 ---

[PATCH v2 26/33] merge-recursive: when comparing files, don't include trees

get_renames() would look up stage data that already existed (populated in get_unmerged(), taken from whatever unpack_trees() created), and if it didn't exist, would call insert_stage_data() to create the necessary entry for the given file. The insert_stage_data() fallback becomes much more

[PATCH v2 06/33] directory rename detection: testcases to avoid taking detection too far

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 150 1 file changed, 150 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 335aa1c145..0ccabed4a2 100755 ---

[PATCH v2 04/33] directory rename detection: basic testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 430 1 file changed, 430 insertions(+) create mode 100755 t/t6043-merge-rename-directories.sh diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v2 29/33] merge-recursive: fix overwriting dirty files involved in renames

This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of directy files that are involved in directory rename detection will be added in a

[PATCH v2 25/33] merge-recursive: check for file level conflicts then get new name

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the file level either. If there aren't any, then get the new name from any directory renames. Signed-off-by: Elijah Newren --- merge-recursive.c

[PATCH v2 22/33] merge-recursive: check for directory level conflicts

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the directory level. There will be additional checks at the individual file level too, which will be added later. Signed-off-by: Elijah Newren

[PATCH v2 24/33] merge-recursive: add computation of collisions due to dir rename & merging

directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths.

[RFC PATCH v2 8/9] merge-recursive: accelerate rename detection

If a file is unmodified on one side of history (no content changes, no name change, and no mode change) and is renamed on the other side, then the correct merge result is to take both the file name and the file contents (and file mode) of the renamed file. merge-recursive detects this rename and

[RFC PATCH v2 6/9] merge-recursive: improve handling for rename/rename(2to1) conflicts

This makes the rename/rename(2to1) conflicts use the new handle_file_collision() function. Since that function was based originally on the rename/rename(2to1) handling code, the main differences here are in what was added. In particular: * If the two colliding files are similar, instead of

[RFC PATCH v2 7/9] merge-recursive: improve handling for add/add conflicts

This makes add/add conflicts use the new handle_file_collision() function. This leaves the handling of the index the same, but modifies how the working tree is handled: instead of always doing a two-way merge of the file contents and recording them at the collision path name, we instead first

[RFC PATCH v2 4/9] Add testcases for improved file collision conflict handling

Adds testcases dealing with file collisions for the following types of conflicts: * add/add * rename/add * rename/rename(2to1) These tests include expectations for new, smarter behavior provided by handle_file_collision(). Since that function is not in use yet, the tests are currently

[RFC PATCH v2 5/9] merge-recursive: fix rename/add conflict handling

This makes the rename/add conflict handling make use of the new handle_file_collision() function, which fixes several bugs and improves things for the rename/add case significantly. Previously, rename/add would: * Not leave any higher order stage entries in the index, making it appear as

[PATCH v4 4/8] connect: split ssh command line options into separate function

The git_connect function is growing long. Split the portion that discovers an ssh command and options it accepts before the service name and path to a separate function to make it easier to read. No functional change intended. Signed-off-by: Jonathan Nieder Reviewed-by:

[RFC PATCH v2 9/9] diffcore-rename: filter rename_src list when possible

We have to look at each entry in rename_src a total of rename_dst_nr times. When we're not detecting copies, any exact renames or ignorable rename paths will just be skipped over. While checking that these can be skipped over is a relatively cheap check, it's still a waste of time to do that

[PATCH 5/8] connect: split ssh option computation to its own function

This puts the determination of options to pass to each ssh variant (see ssh.variant in git-config(1)) in one place. A follow-up patch will use this in an initial dry run to detect which variant to use when the ssh command is ambiguous. No functional change intended yet. Signed-off-by: Jonathan

Re(2): [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, 20 Nov 2017 22:00:10, Ævar Arnfjörð Bjarmason replied: > [...] Thanks for responding. I'll readily confess that PERL and the PERL ecosystem are not areas I'm very familiar with, so I'm really grateful for your feedback here. > You need to bust the perl/PM.stamp cache as a function of

[PATCH v2 00/33] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the previous series, design considerations, etc. Changes since the first series include: * Rebased on latest master (addressing a couple minor

[PATCH v2 14/33] directory rename detection: tests for handling overwriting dirty files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 436 1 file changed, 436 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 7408c788fc..88243651f7 100755 ---

[PATCH v2 09/33] directory rename detection: testcases checking which side did the rename

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 321 1 file changed, 321 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 29b2af7f19..5db2986de8 100755 ---

[PATCH v2 08/33] directory rename detection: files/directories in the way of some renames

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 320 1 file changed, 320 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 1dcf010aa6..29b2af7f19 100755 ---

[PATCH v2 07/33] directory rename detection: partially renamed directory testcase/discussion

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 104 1 file changed, 104 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 0ccabed4a2..1dcf010aa6 100755 ---

[PATCH v2 15/33] merge-recursive: move the get_renames() function

I want to re-use some other functions in the file without moving those other functions or dealing with a handful of annoying split function declarations and definitions. Signed-off-by: Elijah Newren --- merge-recursive.c | 139

Re: [PATCH 3/8] connect: split git:// setup into a separate function

Brandon Williams wrote: > On 11/20, Jonathan Nieder wrote: >> +/* These underlying connection commands die() if they >> + * cannot connect. >> + */ > > I know this is really just code motion but maybe we can fix the style of > the comment here? How about doing that as a separate

[PATCH v2 01/33] Tighten and correct a few testcases for merging and cherry-picking

t3501 had a testcase originally added in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that

Re: [PATCH 4/8] connect: split ssh command line options into separate function

Hi, Brandon Williams wrote: > On 11/20, Jonathan Nieder wrote: [long stream of quoted context snipped; please cut down the quoted text to what you are replying to in the future] >> @@ -972,16 +1031,13 @@ struct child_process *git_connect(int fd[2], const >> char *url, >>

Re: [PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH

On 11/20, Jonathan Nieder wrote: > Previously: [1]. > > This version should be essentially identical to v2. Changes: > - patch 1 is new and should fix the test failure on Windows > - patch 2 is new, discussed at [2] > - patch 5 split off from patch 6 as suggested at [3] > - patch 6 commit

Re: Re(2): [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Nov 20 2017, Dan Jacques jotted: > On Mon, 20 Nov 2017 22:00:10, Ævar Arnfjörð Bjarmason replied: > >> [...] > > Thanks for responding. I'll readily confess that PERL and the PERL > ecosystem are not areas I'm very familiar with, so I'm really grateful > for your feedback here. > >> You

[PATCH] list-objects-filter-options: fix up some sparse warnings

In particular, sparse complains that the armor_{en,de}code_arg() functions are 'not declared - should they be static?'. Since the armor_decode_arg() symbol does not require more than file visibility, we can simply mark the declaration with static. The armor_encode_arg() function has no callers,

Re: [PATCH 1/5] p5550: factor our nonsense-pack creation

On Mon, Nov 20, 2017 at 3:26 PM, Jeff King wrote: > p5550: factor our nonsense-pack creation s/our/out/, I guess. > We have a function to create a bunch of irrelevant packs to > measure the expense of reprepare_packed_git(). Let's make > that available to other perf scripts. > >

[PATCH 6/8] ssh: 'auto' variant to select between 'ssh' and 'simple'

Android's "repo" tool is a tool for managing a large codebase consisting of multiple smaller repositories, similar to Git's submodule feature. Starting with Git 94b8ae5a (ssh: introduce a 'simple' ssh variant, 2017-10-16), users noticed that it stopped handling the port in ssh:// URLs. The

[PATCH 7/8] ssh: 'simple' variant does not support -4/-6

If the user passes -4/--ipv4 or -6/--ipv6 to "git fetch" or "git push" and the ssh command configured with GIT_SSH does not support such a setting, error out instead of ignoring the option and continuing. Signed-off-by: Jonathan Nieder Acked-by: Stefan Beller

Re: [PATCH 3/8] connect: split git:// setup into a separate function

On 11/20, Jonathan Nieder wrote: > The git_connect function is growing long. Split the > PROTO_GIT-specific portion to a separate function to make it easier to > read. > > No functional change intended. > > Signed-off-by: Jonathan Nieder > Reviewed-by: Stefan Beller

[PATCH v2 03/33] merge-recursive: add explanation for src_entry and dst_entry

If I have to walk through the debugger and inspect the values found in here in order to figure out their meaning, despite having known these things inside and out some years back, then they probably need a comment for the casual reader to explain their purpose. Signed-off-by: Elijah Newren

Re: [PATCH 6/8] ssh: 'auto' variant to select between 'ssh' and 'simple'

On 11/20, Jonathan Nieder wrote: > Android's "repo" tool is a tool for managing a large codebase > consisting of multiple smaller repositories, similar to Git's > submodule feature. Starting with Git 94b8ae5a (ssh: introduce a > 'simple' ssh variant, 2017-10-16), users noticed that it stopped >

Re: [PATCH] git-send-email: fix --cc-cmd get_maintainer.pl regression

On Mon, Nov 20, 2017 at 6:41 AM, Alex Bennée wrote: > Since the removal of Mail::Address from git-send-email certain address > patterns returned by common get_maintainer.pl scripts now fail to get > correctly parsed by the built-in Git::parse_mailboxes. Specifically > the

[PATCH 8/8] ssh: 'simple' variant does not support --port

When trying to connect to an ssh:// URL with port explicitly specified and the ssh command configured with GIT_SSH does not support such a setting, it is less confusing to error out than to silently suppress the port setting and continue. This requires updating the GIT_SSH setting in

Re: [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself

On 11/20, Jonathan Nieder wrote: > Simplify by not allowing the copied ssh wrapper to persist between > tests. This way, tests can be safely reordered, added, and removed > with less fear of hidden side effects. > > This also avoids having to call setup_ssh_wrapper to restore the value > of

Re: [PATCH 6/6] grep: show non-empty lines before functions with -W

Am 20.11.2017 um 21:39 schrieb Stefan Beller: > On Sat, Nov 18, 2017 at 10:08 AM, René Scharfe wrote: >> Non-empty lines before a function definition are most likely comments >> for that function and thus relevant. Include them in function context. >> >> Such a non-empty line might

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

A few more comments/observations... On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée wrote: > diff --git a/perl/Git.pm b/perl/Git.pm > @@ -936,6 +936,9 @@ sub parse_mailboxes { > $end_of_addr_seen = 0; > } elsif ($token =~ /^\(/) { >

[PATCH 1/1] diffcore: add a filter to find a specific blob

Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) One might be tempted to extend git-describe to also work with blobs, such that `git describe ` gives a description as ':'. This was

[PATCH 0/1] Teaching the diff machinery about blobfind [WAS: git describe ]

This seems to be an easier approach; thanks Junio for hinting at it. This certainly solves our immediate needs, we may want to build 'git describe ' on top of it or defer it until later. Thanks, Stefan previous descussion https://public-inbox.org/git/20171028004419.10139-1-sbel...@google.com/

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

On Mon, Nov 20, 2017 at 5:44 AM, Alex Bennée wrote: > Eric Sunshine writes: >> It is not at all clear, based upon this text, what this is fixing. >> When you re-roll, please provide a description of the regression in >> sufficient detail for

Re: [PATCH] Makefile: check that tcl/tk is installed

Hi, On Mon, Nov 20, 2017 at 8:19 PM, Jonathan Nieder wrote: > Hi, > > Christian Couder wrote: > >> By default running `make install` in the root directory of the >> project will set TCLTK_PATH to `wish` and then go into the "git-gui" >> and "gitk-git" sub-directories to build

[PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

In theory nobody should ever ask the low-level object code for a null sha1. It's used as a sentinel for "no such object" in lots of places, so leaking through to this level is a sign that the higher-level code is not being careful about its error-checking. In practice, though, quite a few code

[PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH

Previously: [1]. This version should be essentially identical to v2. Changes: - patch 1 is new and should fix the test failure on Windows - patch 2 is new, discussed at [2] - patch 5 split off from patch 6 as suggested at [3] - patch 6 commit message got two new notes to address the worries

[PATCH 4/8] connect: split ssh command line options into separate function

The git_connect function is growing long. Split the portion that discovers an ssh command and options it accepts before the service name and path to a separate function to make it easier to read. No functional change intended. Signed-off-by: Jonathan Nieder Reviewed-by:

Re: [PATCH] contrib/git-jump: allow to configure the grep command

Jeff King wrote: > Subject: [PATCH] git-jump: give contact instructions in the README > > Let's make it clear how patches should flow into > contrib/git-jump. The normal Git maintainer does not > necessarily care about things in contrib/, and authors of > individual components should be the ones

[PATCH 0/5] avoiding pointless pack-directory re-scans

I recently dug into a performance problem running "git fetch" in a repository with 5000 packs. Now obviously that's a silly number of packs to have, but I did find some pretty low-hanging fruit. Most of the time was spent in pointlessly re-scanning the objects/pack directory. This series has two

[PATCH 1/5] p5550: factor our nonsense-pack creation

We have a function to create a bunch of irrelevant packs to measure the expense of reprepare_packed_git(). Let's make that available to other perf scripts. Signed-off-by: Jeff King --- t/perf/lib-pack.sh | 29 + t/perf/p5550-fetch-tags.sh | 25

[PATCH 3/8] connect: split git:// setup into a separate function

The git_connect function is growing long. Split the PROTO_GIT-specific portion to a separate function to make it easier to read. No functional change intended. Signed-off-by: Jonathan Nieder Reviewed-by: Stefan Beller --- As before. connect.c | 103

  1   2   >