Hi,
Matthew DeVore wrote:
> On Sun, Jun 09, 2019 at 10:17:19AM +0200, Johannes Schindelin wrote:
>> I find that it makes sense in general to suppress one's urges regarding
>> introducing `{ ... }` around one-liners when the patch does not actually
>> require it.
>>
>> For example, I found this pa
On Mon, Jun 10, 2019 at 01:13:54PM -0700, Junio C Hamano wrote:
> Matthew DeVore writes:
>
> > - filter_options->filter_spec = strdup(core_partial_clone_filter_default);
> > + if (!filter_options->filter_spec.buf)
> > + strbuf_init(&filter_options->filter_spec, 0);
>
> This part ma
On Sun, Jun 09, 2019 at 10:17:19AM +0200, Johannes Schindelin wrote:
> > if (get_ref_atom_value(a, s->atom, &va, &err))
> > die("%s", err.buf);
> > if (get_ref_atom_value(b, s->atom, &vb, &err))
> > die("%s", err.buf);
> > strbuf_release(&err);
> > cmp_fn = s
On 6/10/2019 5:47 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>> +if (get_oid_hex(line.buf, &oids[i])) {
>> +warning(_("invalid commit-graph chain: line '%s' not a
>> hash"),
>> +line.buf);
>> +
From: Derrick Stolee
The 'git multi-pack-index repack' command can take a batch size of
zero, which creates a new pack-file containing all objects in the
multi-pack-index. The first 'repack' command will create one new
pack-file, and an 'expire' command after that will delete the old
pack-files,
The multi-pack-index provides a fast way to find an object among a large
list of pack-files. It stores a single pack-reference for each object id, so
duplicate objects are ignored. Among a list of pack-files storing the same
object, the most-recently modified one is used.
Create new subcommands fo
From: Derrick Stolee
Before writing the multi-pack-index, we compute the length of the
pack-index names concatenated together. This forms the data in the
pack name chunk, and we precompute it to compute chunk offsets.
The value is also modified to fit alignment needs.
Previously, this computatio
From: Derrick Stolee
During development of the multi-pack-index expire subcommand, a
version went out that improperly computed the pack order if a new
pack was introduced while other packs were being removed. Part of
the subtlety of the bug involved the new pack being placed before
other packs th
From: Derrick Stolee
To repack with a non-zero batch-size, first sort all pack-files by
their modified time. Second, walk those pack-files from oldest
to newest, compute their expected size, and add the packs to a list
if they are smaller than the given batch-size. Stop when the total
expected si
From: Derrick Stolee
The 'git multi-pack-index expire' subcommand may delete packs that
are not needed from the perspective of the multi-pack-index. If
a pack has a .keep file, then we should not delete that pack. Add
a test that ensures we preserve a pack that would otherwise be
expired. First,
From: Derrick Stolee
In anticipation of the expire subcommand, refactor the way we sort
the packfiles by name. This will greatly simplify our approach to
dropping expired packs from the list.
First, create 'struct pack_info' to replace 'struct pack_pair'.
This struct contains the necessary infor
From: Derrick Stolee
The 'git multi-pack-index expire' subcommand looks at the existing
mult-pack-index, counts the number of objects referenced in each
pack-file, deletes the pack-fils with no referenced objects, and
rewrites the multi-pack-index to no longer reference those packs.
Refactor the
From: Derrick Stolee
In an environment where the multi-pack-index is useful, it is due
to many pack-files and an inability to repack the object store
into a single pack-file. However, it is likely that many of these
pack-files are rather small, and could be repacked into a slightly
larger pack-fi
From: Derrick Stolee
The repack builtin deletes redundant pack-files and their
associated .idx, .promisor, .bitmap, and .keep files. We will want
to re-use this logic in the future for other types of repack, so
pull the logic into 'unlink_pack_path()' in packfile.c.
The 'ignore_keep' parameter i
From: Derrick Stolee
The multi-pack-index tracks objects in a collection of pack-files.
Only one copy of each object is indexed, using the modified time
of the pack-files to determine tie-breakers. It is possible to
have a pack-file with no referenced objects because all objects
have a duplicate
From: Derrick Stolee
We will add new subcommands to the multi-pack-index, and that will
make the documentation a bit messier. Clean up the 'verb'
descriptions by renaming the concept to 'subcommand' and removing
the reference to the object directory.
Helped-by: Stefan Beller
Helped-by: Szeder G
On 2019-06-10 at 07:57:18, Eric Sunshine wrote:
> On Sun, Jun 9, 2019 at 6:44 PM brian m. carlson
> wrote:
> > Replace several hard-coded full and partial object IDs with variables or
> > computed values. Create junk data to stuff inside an invalid tree that
> > can be either 20 or 32 bytes long.
Am 10.06.19 um 19:21 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> +# here, $IFS is just a LF
>> +for line in $f
>> +do
>> +mode=${line%% *}# 1st word
>> +sha1=${line#"$mode "}
>> +sha1=${sha1%% *}# 2nd word
>>
"Derrick Stolee via GitGitGadget" writes:
> + fp = fopen(chain_name, "r");
> + stat_res = stat(chain_name, &st);
> + free(chain_name);
> +
> + if (!fp ||
> + stat_res ||
> + st.st_size <= the_hash_algo->hexsz)
> + return NULL;
> +
> + count = st.st_
Am 10.06.19 um 19:17 schrieb Junio C Hamano:
> Johannes Sixt writes:
>> git-mergetool spawns an enormous amount of processes. For this reason,
>> the test script, t7610, is exceptionally slow, in particular, on
>> Windows. Most of the processes are invocations of git, but there are
>> also some th
On Mon, Jun 10, 2019 at 5:27 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> >> +#include
> >> +#include "builtin.h"
> >
> > Git source files must always include cache.h or git-compat-util.h (or,
> > for builtins, builtin.h) as the very first header since those headers
> > take care of differ
Eric Sunshine writes:
>> +/*
>> + * "git walken"
>> + *
>> + * Part of the "My First Revision Walk" tutorial.
>> + */
>> +
>> +#include
>> +#include "builtin.h"
>
> Git source files must always include cache.h or git-compat-util.h (or,
> for builtins, builtin.h) as the very first header since th
Emily Shaffer writes:
> +My First Revision Walk
> +==
> +
> +== What's a Revision Walk?
> +
> +The revision walk is a key concept in Git - this is the process that
> underpins
> +operations like `git log`, `git blame`, and `git reflog`. Beginning at HEAD,
> the
> +list of ob
Emily Shaffer writes:
> I'll also be mailing an RFC patchset In-Reply-To this message; the RFC
> patchset should not be merged to Git, as I intend to host it in my own
> mirror as an example. I hosted a similar example for the
> MyFirstContribution tutorial; it's visible at
> https://github.com/n
Matthew DeVore writes:
> - filter_options->filter_spec = strdup(core_partial_clone_filter_default);
> + if (!filter_options->filter_spec.buf)
> + strbuf_init(&filter_options->filter_spec, 0);
This part made me go "Huh?" a bit.
Do we document that .buf==NULL means an uninitia
Hi,
Using SourceTree I issue the Stop Tracking command (I think it executed the add
untracked
https://git-scm.com/docs/git-add#Documentation/git-add.txt-adduntracked). Is
there anyway to revert this command and re-enable the folder? I was able to
re-add to the index all files into the folder b
Jean-Noël AVILA writes:
> I can provide an archive comprising the precompiled manpages so that
> packagers
> don't need to mess up with po4a.
That's an interesting thing to hear---if this effort eventually
relieves me from having to supply preformatted manpages and HTML
docs (after all, en/C i
On Monday, 10 June 2019 19:09:54 CEST Johannes Schindelin wrote:
> Hi Jean-Noël,
>
> On Sun, 9 Jun 2019, Jean-Noël AVILA wrote:
>
> > I took on the task of creating a project for the translation of man-pages
at
> > https://github.com/jnavila/git-manpages-l10n
> >
> > Up to now, the translations
On Mon, Jun 10, 2019 at 08:29:56PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 10 Jun 2019, SZEDER Gábor wrote:
>
> > > diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
> > > index 5b61c10a9c..b67440882b 100755
> > > --- a/t/t7610-mergetool.sh
> > > +++ b/t/t7610-mergetool.sh
> >
Hi Michal
On Mon, 10 Jun 2019, Michal Suchánek wrote:
> I am using git 2.20.1 and just observed this behavior:
Have you tested this with v2.21.0 (which is over three months old by now),
or even v2.22.0?
Ciao,
Johannes
Hi Randall,
On Mon, 10 Jun 2019, Randall S. Becker wrote:
> On Friday, June 7, 2019 5:31 PM, Junio C Hamano wrote:
> > The latest feature release Git v2.22.0 is now available at the
> > usual places. It is comprised of 745 non-merge commits since
> > v2.21.0, contributed by 74 people, 18 of whic
Hi,
On Mon, 10 Jun 2019, SZEDER Gábor wrote:
> > diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
> > index 5b61c10a9c..b67440882b 100755
> > --- a/t/t7610-mergetool.sh
> > +++ b/t/t7610-mergetool.sh
> > @@ -131,13 +131,13 @@ test_expect_success 'custom mergetool' '
> > git checkout -
On 6/10/2019 1:31 PM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> On 5/14/2019 2:47 PM, Derrick Stolee wrote:
>>> Updates in V6:
>>>
>>> I rebased onto ds/midx-too-many-packs. Thanks, Junio for taking that
>>> change first. There were several subtle things that needed to change to
>>> put
Philip Oakley writes:
> The availability of these pattern selections is not obvious from
> the man pages, as per mail thread <87lfz3vcbt@evledraar.gmail.com>.
>
> Provide examples.
>
> Re-order the `git branch` synopsis to emphasise the `--list `
> pairing. Also expand and reposition the `all
On Mon, Jun 10, 2019 at 10:23:57AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > turn these
> >
> > test "$(cat file1)" = "that"'
> >
> > checks into
> >
> > echo that >expect &&
> > test_cmp expect file1
> >
> > because 'test_cmp' on Windows first compares the two files in shel
Hi Rohit
On 10/06/2019 14:33, Rohit Ashiwal wrote:
> Hi Phillip
>
> On 2019-06-10 10:40 UTC Phillip Wood wrote:
>>
>> Hi Rohit
>>
>> On 10/06/2019 06:28, Rohit Ashiwal wrote:
>>> Hey Phillip
>>>
>>> On Sun, 9 Jun 2019 19:03:02 +0100 Phillip Wood
>>> wrote:
Hi Rohit
>>> [...]
>>> I th
Hi Rohit
On 10/06/2019 14:43, Rohit Ashiwal wrote:
> Hi Phillip
>
> On 2019-06-10 10:40 UTC Phillip Wood wrote:
>>
>> [...]
>> It's actually a bit more complicated as if the cherry-pick failed
>> because it would have overwriten untracked files then CHERRY_PICK_HEAD
>> will not exist but we want
Hi Rohit
On 10/06/2019 14:25, Rohit Ashiwal wrote:
> Hi Phillip
>
> On 2019-06-10 10:39 UTC Phillip Wood wrote:
>>
>> Hi Rohit
>>
>> On 10/06/2019 06:13, Rohit Ashiwal wrote:
>>>
>>> [...]
>>> Firstly, signature of `create_seq_dir` doesn't allow us to call
>>> `sequencer_get_last_command()`. Cha
Derrick Stolee writes:
> On 5/14/2019 2:47 PM, Derrick Stolee wrote:
>> Updates in V6:
>>
>> I rebased onto ds/midx-too-many-packs. Thanks, Junio for taking that
>> change first. There were several subtle things that needed to change to
>> put this change on top:
>> ...
> However, this series wa
SZEDER Gábor writes:
> turn these
>
> test "$(cat file1)" = "that"'
>
> checks into
>
> echo that >expect &&
> test_cmp expect file1
>
> because 'test_cmp' on Windows first compares the two files in shell
> and runs 'diff' only when there is a difference to report.
Needs measuring. Is two
Johannes Sixt writes:
> + # here, $IFS is just a LF
> + for line in $f
> + do
> + mode=${line%% *}# 1st word
> + sha1=${line#"$mode "}
> + sha1=${sha1%% *}# 2nd word
> + case "${line#$mode $sha1 }" in # r
Johannes Sixt writes:
> git-mergetool spawns an enormous amount of processes. For this reason,
> the test script, t7610, is exceptionally slow, in particular, on
> Windows. Most of the processes are invocations of git, but there are
> also some that can be replaced with shell builtins. Do so with
Hi Jean-Noël,
On Sun, 9 Jun 2019, Jean-Noël AVILA wrote:
> I took on the task of creating a project for the translation of man-pages at
> https://github.com/jnavila/git-manpages-l10n
>
> Up to now, the translations have started for 3 languages:
>
> * German (2 pages)
> * Brazilian Portuguese (6 p
Hi, everyone
I've been working on making the pack access code thread safe, as my
GSoC project[1]. I was working directly at sha1-file.c global states
targeting, in the far distance, to parallelize git-blame. But my
mentors and I decided to take a different path, as a better way to
continuous valid
SZEDER Gábor writes:
> So, 'test oidmap' from the previous patch prints the value we want to
> check with:
>
> printf("%u\n", sha1hash(oid.hash));
>
> First, since object ids inherently make more sense as hex values, it
> would be more appropriate to print that hash with the '%x' format
> spe
"brian m. carlson" writes:
>> test_expect_success 'init with separate gitdir' '
>> rm -rf newdir &&
>> git init --separate-git-dir realgitdir newdir &&
>> echo "gitdir: $(pwd)/realgitdir" >expected &&
>> +downcase_on_case_insensitive_fs expected newdir/.git &&
>
> I wonder if
Phillip Wood writes:
>> Firstly, signature of `create_seq_dir` doesn't allow us to call
>> `sequencer_get_last_command()`. Changing that for the sake of a
>> better error message is too much task for this patch as it is a
>> subject of discussion on its own.
>
> There is only one caller and it al
Jeff King writes:
> Your patch only helps with this at all because you're using the "tree:1"
> ...
> because there you'll have actual names which cat-file will choke on. So
> it seems like this is helping only a very limited use case.
> ...
> Alternatively, it would be reasonable to me to have an
This commit integrates the fuzzy fingerprint heuristic into
guess_line_blames().
We actually make two passes. The first pass uses the fuzzy algorithm to
find a match within the current diff chunk. If that fails, the second
pass searches the entire parent file for the best match.
For an example
Signed-off-by: Barret Rhoden
---
t/t8003-blame-corner-cases.sh | 36 +++
1 file changed, 36 insertions(+)
diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh
index c92a47b6d5b1..1c5fb1d1f8c9 100755
--- a/t/t8003-blame-corner-cases.sh
+++ b/t
From: Michael Platings
This algorithm will replace the heuristic used to identify lines from
ignored commits with one that finds likely candidate lines in the
parent's version of the file. The actual replacement occurs in an
upcoming commit.
The old heuristic simply assigned lines in the target
When ignoring commits, the commit that is blamed might not be
responsible for the change, due to the inaccuracy of our heuristic.
Users might want to know when a particular line has a potentially
inaccurate blame.
Furthermore, guess_line_blames() may fail to find any parent commit for
a given line
fill_blame_origin() is a convenient place to store data that we will use
throughout the lifetime of a blame_origin. Some heuristics for
ignoring commits during a blame session can make use of this storage.
In particular, we will calculate a fingerprint for each line of a file
for blame_origins inv
The same code for splitting a blame_entry at a particular line was used
twice in blame_chunk(), and I'll use the helper again in an upcoming
patch.
Signed-off-by: Barret Rhoden
---
blame.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff
Commits that make formatting changes or function renames are often not
interesting when blaming a file. A user may deem such a commit as 'not
interesting' and want to ignore and its changes it when assigning blame.
For example, say a file has the following git history / rev-list:
---O---A---X---
This patch set adds the ability to ignore a set of commits and their
changes when blaming. This can be used to ignore a commit deemed 'not
interesting,' such as reformatting.
The main changes to this patchset from previous versions are in the area
of test portability and coverage.
v7 -> v8
v7: h
Signed-off-by: Barret Rhoden
---
fsck.c | 35 ---
oidset.c | 35 +++
oidset.h | 8
3 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/fsck.c b/fsck.c
index a28cba6b05dd..58ff3c4de992 100644
--- a/fsck.c
+++
init_skiplist() took a file consisting of SHA-1s and comments and added
the objects to an oidset. This functionality is useful for other
commands and will be moved to oidset.c in a future commit.
In preparation for that move, this commit renames it to
oidset_parse_file() to reflect its more gener
On 6/4/19 8:57 PM, Derrick Stolee wrote:
[snip]
I think you should just make the test be complete by
checking a post-condition. Please see the inserted lines
below (which _should_ work, I haven't actually ran this
in the test suite).
With a little massaging, this did the trick. I'll roll the p
Hello,
there is an issue with rebase vs am separation.
I am using git 2.20.1 and just observed this behavior:
- rebase started ( possibly with previous am in progress on
different branch - not known)
- rebase stopped, used am --skip to continue
- renase was not able to finish
Does anybod
On 6/10/2019 8:26 AM, SZEDER Gábor wrote:
On Sat, Jun 08, 2019 at 07:42:42AM -0700, Jeff Hostetler via GitGitGadget wrote:
From: Jeff Hostetler
Teach register_rename_src() to see if new file pair
can simply be appended to the rename_src[] array before
performing the binary search to find th
On 6/8/2019 10:42 AM, Johannes Schindelin via GitGitGadget wrote:
Just another patch from Git for Windows' branch thicket...
Jeff Hostetler (1):
diffcore-rename: speed up register_rename_src
diffcore-rename.c | 13 +
1 file changed, 13 insertions(+)
base-commit: 8104ec994
On 6/8/2019 6:27 PM, René Scharfe wrote:
Am 08.06.19 um 16:42 schrieb Jeff Hostetler via GitGitGadget:
From: Jeff Hostetler
Teach register_rename_src() to see if new file pair
can simply be appended to the rename_src[] array before
performing the binary search to find the proper insertion
p
On 5/14/2019 2:47 PM, Derrick Stolee wrote:
> Updates in V6:
>
> I rebased onto ds/midx-too-many-packs. Thanks, Junio for taking that
> change first. There were several subtle things that needed to change to
> put this change on top:
>
> * We need a repository struct everywhere since we add pack-
On Fri, May 24, 2019 at 12:14 PM Orgad Shaneh wrote:
>
> Hi,
>
> git fetch in my repository *when nothing new is received* takes 2.5x
> the time when comparing 2.20 against 2.21 (on Windows it's 4x).
>
> I have 5 initialized submodules in this working directory.
>
> I reported this issue on git-fo
Hi Phillip
On 2019-06-10 10:40 UTC Phillip Wood wrote:
>
> [...]
> It's actually a bit more complicated as if the cherry-pick failed
> because it would have overwriten untracked files then CHERRY_PICK_HEAD
> will not exist but we want to be able to skip that pick. So it should
> not error out in
Hi Phillip
On 2019-06-10 10:40 UTC Phillip Wood wrote:
>
> Hi Rohit
>
> On 10/06/2019 06:28, Rohit Ashiwal wrote:
>> Hey Phillip
>>
>> On Sun, 9 Jun 2019 19:03:02 +0100 Phillip Wood
>> wrote:
>>>
>>> Hi Rohit
>> [...]
>> I think it is more about suggesting what are all the possibilities
>> you
On Friday, June 7, 2019 5:31 PM, Junio C Hamano wrote:
> The latest feature release Git v2.22.0 is now available at the
> usual places. It is comprised of 745 non-merge commits since
> v2.21.0, contributed by 74 people, 18 of which are new faces.
Report from NonStop tests:
t7519 subtest 25 still
Hi Phillip
On 2019-06-10 10:39 UTC Phillip Wood wrote:
>
>Hi Rohit
>
>On 10/06/2019 06:13, Rohit Ashiwal wrote:
>>
>> [...]
>> Firstly, signature of `create_seq_dir` doesn't allow us to call
>> `sequencer_get_last_command()`. Changing that for the sake of a
>> better error message is too much tas
On Sat, Jun 08, 2019 at 07:42:42AM -0700, Jeff Hostetler via GitGitGadget wrote:
> From: Jeff Hostetler
>
> Teach register_rename_src() to see if new file pair
> can simply be appended to the rename_src[] array before
> performing the binary search to find the proper insertion
> point.
>
> This
Am 01.05.19 um 20:18 schrieb Jeff King:
> On Wed, May 01, 2019 at 07:45:05PM +0200, René Scharfe wrote:
>
>>> But since the performance is still not quite on par with `gzip`, I would
>>> actually rather not, and really, just punt on that one, stating that
>>> people interested in higher performance
Hi Rohit
On 10/06/2019 06:28, Rohit Ashiwal wrote:
> Hey Phillip
>
> On Sun, 9 Jun 2019 19:03:02 +0100 Phillip Wood
> wrote:
>>
>> Hi Rohit
>>
>> On 08/06/2019 20:19, Rohit Ashiwal wrote:
>>> [...]
>>> @@ -2654,8 +2654,8 @@ static int create_seq_dir(void)
>>> {
>>> if (file_exists(git_path
Hi Rohit
On 10/06/2019 06:13, Rohit Ashiwal wrote:
> Hi Philip
>
> On 2019-06-09 17:52 UTC Phillip Wood wrote:
>>
>> Hi Rohit
>>
>> Congratulations on your first GSoC patch series!
>
> Thank you very much :)
>
>> On 08/06/2019 20:19, Rohit Ashiwal wrote:
>>> [...]
>>> @@ -2655,6 +2655,7 @@ sta
Hi Rohit
On 10/06/2019 06:57, Rohit Ashiwal wrote:
> Hey Phillip
>
> On Sun, 9 Jun 2019 19:01:35 +0100 Phillip Wood
> wrote:
>>
>> Hi Rohit
>>
>> --skip is definitely a useful addition to cherry-pick/revert
>>
>> On 08/06/2019 20:19, Rohit Ashiwal wrote:
>>>
>>> [...]
>>> @@ -2784,6 +2784,29 @@
On Mon, Jun 10, 2019 at 10:58:58AM +0200, Johannes Sixt wrote:
> Subshells for pipelines are not required. This can save a number of
> processes (if the shell does not optimize it away anyway).
>
> The patch was generated with the command
>
>sed -i 's/( *\(yes.*[^ ]\) *) *\&\&/\1 \&\&/' t7610
I just used git-send-email the first time since ages. When it finished,
I saw a stream of 16 warnings:
Warning: unable to close filehandle properly: Bad file descriptor during
global destruction.
The invocation was this:
git send-email --to git@vger.kernel.org patches
where the argument 'pat
git-mergetool spawns an enormous amount of processes. For this reason,
the test script, t7610, is exceptionally slow, in particular, on
Windows. Most of the processes are invocations of git, but there are
also some that can be replaced with shell builtins.
I've measured the number of processes wit
Subshells for pipelines are not required. This can save a number of
processes (if the shell does not optimize it away anyway).
The patch was generated with the command
sed -i 's/( *\(yes.*[^ ]\) *) *\&\&/\1 \&\&/' t7610-mergetool.sh
with a manual fixup of the case having no && at the end.
Si
git-mergetool spawns an enormous amount of processes. For this reason,
the test script, t7610, is exceptionally slow, in particular, on
Windows. Most of the processes are invocations of git, but there are
also some that can be replaced with shell builtins. Do so with `expr`.
Signed-off-by: Johanne
git-mergetool spawns an enormous amount of processes. For this reason,
the test script, t7610, is exceptionally slow, in particular, on
Windows. Most of the processes are invocations of git, but there are
also some that can be replaced with shell builtins. Avoid repeated
calls of `git ls-files` and
On Sun, Jun 9, 2019 at 6:44 PM brian m. carlson
wrote:
> Replace several hard-coded full and partial object IDs with variables or
> computed values. Create junk data to stuff inside an invalid tree that
> can be either 20 or 32 bytes long. Compute a binary all-zeros object ID
> instead of hard-c
81 matches
Mail list logo
