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
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
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
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
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))
> > +
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,
(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
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
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
>
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
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
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
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
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
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,
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
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
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
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
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
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
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
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(+)
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
---
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
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 |
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
---
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
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
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
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
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
---
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
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
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
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
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
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],
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
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
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
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
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:
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
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
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,
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
---
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
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.
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
---
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
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
---
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
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
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
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
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.
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
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
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
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
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
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:
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
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
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
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
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
---
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
---
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
---
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
---
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
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
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
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,
>>
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
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
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,
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.
>
>
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
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
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
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
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
>
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
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
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
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
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 =~ /^\(/) {
>
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
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/
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
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
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
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
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:
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
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
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
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 - 100 of 153 matches
Mail list logo