These flags were there since the beginning (3443546f6e (Use a *real*
built-in diff generator, 2006-03-24), but were never used. Remove them.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
xdiff/xdiff.h | 8
1 file changed, 8 deletions(-)
diff --git a/xdiff/xdiff.h b/xd
The new "blocks" mode provides a middle ground between plain and zebra.
It is as intuitive (few colors) as plain, but still has the requirement
for a minimum of lines/characters to count a block as moved.
Suggested-by: Ævar Arnfjörð Bjarmason
(https://public-inbox.org/git/87o9j0uljo@evledraa
Signed-off-by: Stefan Beller
---
Documentation/config.txt | 5 +
Documentation/diff-options.txt | 7 +--
diff.c | 9 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2659153cb3
This moves the part of code that checks if we're still in a block
into its own function. We'll need a different approach on advancing
the blocks in a later patch, so having it as a separate function will
prove useful.
While at it rename the variable `p` to `prev` to indicate that it refers
to the
There is no need to forward-declare these functions, as they are used
after their implementation only.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
xdiff/xdiffi.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 0de1ef
This makes the follow up patch easier.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index ce7bedc1b92..d1bae900cdc 100644
--- a/diff.c
+++ b/diff.c
@@ -707,11 +707,15 @@
In t4015 we have a pattern of
git diff [] |
grep -v "index" |
test_decode_color >actual &&
to produce output that we want to test against. This pattern was introduced
in 86b452e2769 (diff.c: add dimming to moved line detection, 2017-06-30)
as then the focus on getting the colo
When we initialize the hashmap, we give it a pointer to the
diff_options, which it then passes along to each call of the
hashmap_cmp_fn function. There's no need to pass it a second time as
the "keydata" parameter, and our comparison functions never look at
keydata.
This was a mistake left over fr
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To jus
In the original implementation of the move detection logic the choice for
ignoring white space changes is the same for the move detection as it is
for the regular diff. Some cases came up where different treatment would
have been nice.
Allow the user to specify that white space should be ignored
Hi Eric,
On Tue, Jul 17, 2018 at 11:59 AM Eric Sunshine wrote:
>
> On Tue, Jul 17, 2018 at 2:53 PM Stefan Beller wrote:
> > > A tangent.
> > >
> > > Because this "-- " is a conventional signature separator, MUAs like
> > > Emacs message-mode seems to omit everything below it from the quote
> > >
On Wed, Jul 18, 2018 at 8:00 AM Derrick Stolee wrote:
>
> On 7/12/2018 3:47 PM, Stefan Beller wrote:
> > + fprintf(stdout, submodule_strategy_to_string(&update_strategy));
>
> This line is causing build failures on 'pu' for certain setups:
>
yeah, will fix in a resend.
originally reported at
On Wed, Jul 18, 2018 at 08:15:41AM -0700, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> Create new method commit_graph_compatible(r) to check if a given
> repository r is compatible with the commit-graph feature. Fill the
> method with a check to see if replace-objects exist.
On Wed, Jul 18, 2018 at 03:46:57PM -0400, Jeff King wrote:
> On Wed, Jul 18, 2018 at 08:15:41AM -0700, Derrick Stolee via GitGitGadget
> wrote:
>
> > From: Derrick Stolee
> >
> > Create new method commit_graph_compatible(r) to check if a given
> > repository r is compatible with the commit-gra
This fixes the compilation issue raised by SZEDER and Stolee,
6: 3c156c79ae7 ! 6: f82f24e73b6 submodule--helper: introduce new
update-module-mode helper
@@ -10,7 +10,6 @@
for arbitrary repositories.
Signed-off-by: Stefan Beller
-Signed-off-by: Junio C Haman
All other error messages in cmd_update are reporting the submodule based
on its path, so let's do that for invalid update modes, too.
Signed-off-by: Stefan Beller
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5f
The information that is printed for update_submodules in
'submodule--helper update-clone' and consumed by 'git submodule update'
is stored as a string per submodule. This made sense at the time of
48308681b07 (git submodule update: have a dedicated helper for cloning,
2016-02-29), but as we want to
In a later patch we'll find this method handy.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index fb54936efc7..034ba1bb2e0 100644
-
This chews off a bit of the shell part of the update command in
git-submodule.sh. When writing the C code, keep in mind that the
submodule--helper part will go away eventually and we want to have
a C function that is able to determine the submodule update strategy,
it as a nicety, make determine_su
Separate the command line parsing from the actual execution of the command
within the repository. For now there is not a lot of execution as
most of it is still in git-submodule.sh.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 59 +
1 file ch
The 'mode' variable is not used in cmd_update for its original purpose,
rename it to 'dummy' as it only serves the purpose to abort quickly
documenting this knowledge.
The variable 'stage' is also not used any more in cmd_update, so remove it.
This went unnoticed as first each function used the c
On 7/18/2018 3:46 PM, Jeff King wrote:
On Wed, Jul 18, 2018 at 08:15:41AM -0700, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
Create new method commit_graph_compatible(r) to check if a given
repository r is compatible with the commit-graph feature. Fill the
method with a check
Jeff King writes:
> On Wed, Jul 18, 2018 at 11:19:01AM -0700, Junio C Hamano wrote:
>
>> > It's also still inconsistent in the daemonize case. The run that yields
>> > the error won't return a non-zero exit. But the next run will exit with
>> > "2".
>>
>> I do not see this particular "inconsiste
On Wed, Jul 18, 2018 at 3:34 PM Stefan Beller wrote:
> On Tue, Jul 17, 2018 at 11:59 AM Eric Sunshine
> wrote:
> > The "git-format-patch --range-diff" option implemented by that patch
> > series (and its upcoming re-roll) place the range-diff before the "--
> > " signature line, so this isn't a
Stefan Beller writes:
>> - existing users of for_each_replace_ref() who were all happy
>>working in the_repository have to pass it explicitly, even
>>thought they do not have any need to.
>
> All callbacks that are passed to for_each_replace_ref now
> operate on 'r' instead of the_reposi
We can already disable replace refs using a command line
option or environment variable, but those are awkward to
apply universally. Let's add a config option to do the same
thing.
That raises the question of why one might want to do so
universally. The answer is that replace refs violate the
immu
On 7/18/2018 4:17 PM, Jeff King wrote:
We can already disable replace refs using a command line
option or environment variable, but those are awkward to
apply universally. Let's add a config option to do the same
thing.
That raises the question of why one might want to do so
universally. The ans
On Wed, Jul 18, 2018 at 04:23:20PM -0400, Derrick Stolee wrote:
> This patch looks good to me. The only thing I saw was when I ran 'git grep
> check_replace_refs' and saw the following in environment.c:
>
> int check_replace_refs = 1; /* NEEDSWORK: rename to read_replace_refs */
>
> This doe
On Wed, Jul 18, 2018 at 1:31 PM Jeff King wrote:
>
> On Wed, Jul 18, 2018 at 04:23:20PM -0400, Derrick Stolee wrote:
>
> > This patch looks good to me. The only thing I saw was when I ran 'git grep
> > check_replace_refs' and saw the following in environment.c:
> >
> > int check_replace_refs =
On Wed, Jul 18, 2018 at 04:31:52PM -0400, Jeff King wrote:
> Since Stefan's patch logically undoes ecef23, I think that's why he
> put in the comment to move back to the old name.
>
> Personally, I do not find one name any more informative than the other,
> and would be happy to leave it as-i
Commit afc711b8e1 (rename read_replace_refs to
check_replace_refs, 2014-02-18) added a comment mentioning
that check_replace_refs is set in two ways:
- from user intent via --no-replace-objects, etc
- after seeing there are no replace refs to respect
Since c3c36d7de2 (replace-object: check_r
Signed-off-by: Ben Peart
---
unpack-trees.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..1f58efc6bb 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1326,6 +1326,7 @@ int unpack_trees(unsigned len, struct tree_desc *t,
struct unpack
Signed-off-by: Ben Peart
---
Makefile| 1 +
mpmcqueue.c | 49
mpmcqueue.h | 80 +
3 files changed, 130 insertions(+)
create mode 100644 mpmcqueue.c
create mode 100644 mpmcqueue.h
diff --git a/Makefile b/M
This was added as a NEEDSWORK in 3c36d7de2 (replace-object:
check_replace_refs is safe in multi repo environment,
2018-04-11), waiting for a calmer period. Since doing so now
doesn't conflict with anything in 'pu', it seems as good a
time as any.
Signed-off-by: Jeff King
---
builtin/fsck.c
When working directories get big, checkout times start to suffer. Even with
GVFS virtualization (which limits git to only having to update those files
that have been changed locally) we�re seeing P50 times for checkout of 31
seconds and the P80 time is 43 seconds.
Here is a checkout command with
Signed-off-by: Ben Peart
---
cache.h| 1 +
config.c | 5 +
environment.c | 1 +
unpack-trees.c | 313 -
unpack-trees.h | 30 +
5 files changed, 348 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index d49092d
We can already disable replace refs using a command line
option or environment variable, but those are awkward to
apply universally. Let's add a config option to do the same
thing.
That raises the question of why one might want to do so
universally. The answer is that replace refs violate the
immu
On Wed, Jul 18, 2018 at 1:45 PM Ben Peart wrote:
>
Did you have any further considerations that are worth recording here?
(memory, performance, CPU execution, threading, would all come to mind)
> Signed-off-by: Ben Peart
> +/*
> + * Initializes a mpmcq structure.
> + */
I'd find the name mpmc
> don�t
The encoding seems to be broken somehow (also on)
https://public-inbox.org/git/20180718204458.20936-1-benpe...@microsoft.com/
> When I brought up this idea with some other git contributors they mentioned
> that multi threading unpack_trees() had been discussed a few years ago on
https:/
On Wed, Jul 18, 2018 at 08:45:14PM +, Ben Peart wrote:
> When working directories get big, checkout times start to suffer. Even with
> GVFS virtualization (which limits git to only having to update those files
> that have been changed locally) we�re seeing P50 times for checkout of 31
> secon
Eric Sunshine writes:
> I did consider placing the range-diff before the diffstat, however,
> what convinced me to position range-diff last was that the diffstat is
> usually short and easy to skip over both visually and via scrolling,
> whereas the range-diff often is long and noisy, thus more d
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Many topics have moved to 'master'
Hi,
I was wondering why "git clone" seems to not respect "-delta" in .gitattributes.
*Reproduction*
I prepared a test repository with:
- git v2.17.1
- .gitattributes containing "*.bin binary -delta"
- 10 commits with a 10 MB random binary file
Code:
---
Stefan Beller writes:
> This fixes the compilation issue raised by SZEDER and Stolee,
>
>
> 6: 3c156c79ae7 ! 6: f82f24e73b6 submodule--helper: introduce new
> update-module-mode helper
> @@ -10,7 +10,6 @@
> for arbitrary repositories.
>
> Signed-off-by: Stefan Belle
Jeff King writes:
> Commit afc711b8e1 (rename read_replace_refs to
> check_replace_refs, 2014-02-18) added a comment mentioning
> that check_replace_refs is set in two ways:
>
> - from user intent via --no-replace-objects, etc
>
> - after seeing there are no replace refs to respect
>
> Since
Jeff King writes:
> This was added as a NEEDSWORK in 3c36d7de2 (replace-object:
I'll do s/3c36d7de2/c&/; while queuing.
Like you, I do not think one is vastly better than the other between
these two names, but since a patch has been written, so ...
> check_replace_refs is safe in multi repo en
This reverts commit 0aca34e8269514ebb67676e0470a314615494ae8.
---
builtin/pack-objects.c | 26 ++
pack-objects.h | 23 +--
2 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 710
---
builtin/pack-objects.c | 2 +-
pack-objects.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 71056d8294..49b7af295d 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2023,7 +2023,7 @@ static
I had a user report some poor behavior of 'git gc --aggressive' on a
certain repo (which I sadly cannot share). Turns out that on this
repo, this operation takes about 60% longer and produces a pack
roughly twice the expected size.
Naturally, bisecting takes a while but it points to this commit:
On Wed, Jul 18, 2018 at 03:41:10PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Commit afc711b8e1 (rename read_replace_refs to
> > check_replace_refs, 2014-02-18) added a comment mentioning
> > that check_replace_refs is set in two ways:
> >
> > - from user intent via --no-replace-ob
On Wed, Jul 18, 2018 at 03:44:36PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > This was added as a NEEDSWORK in 3c36d7de2 (replace-object:
>
> I'll do s/3c36d7de2/c&/; while queuing.
Oops, vi strikes again, I think.
> Like you, I do not think one is vastly better than the other bet
Ben Peart writes:
> + * Fetch the tree from the ODB for each peer directory in the
> + * n commits.
> + *
> + * For 2- and 3-way traversals, we try to avoid hitting the
> + * ODB twice for the same OID. This should yield a nice speed
> + * up in checkouts and merges
Hello,
On 17.07.2018 20:45, Duy Nguyen wrote:
Since get_oid() callers must handle failure when it returns non-zero,
I would say "gently" is already implied by get_oid() and we could just
convert those die() to error() or warning(). Unless some of those
die() are very special that we need to choo
Hello,
On 17.07.2018 21:55, Junio C Hamano wrote:
I wonder if the GENTLY option should apply to update_tree_entry()
the same way as it would to the other codepaths that currently die
to express "we were handed this string by the caller and told to
give back object ID the string represents, and w
On Wed, Jul 18, 2018 at 3:24 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > This fixes the compilation issue raised by SZEDER and Stolee,
> >
> >
> > 6: 3c156c79ae7 ! 6: f82f24e73b6 submodule--helper: introduce new
> > update-module-mode helper
> > @@ -10,7 +10,6 @@
> >
Hello,
This points us back to "only-to-die" which was "gently" before
2e83b66c ("fix overslow :/no-such-string-ever-existed diagnostics",
2011-05-10). I think we have to keep them both, as only-to-die
means more than just being not gentle, and we cannot revert the
renaming s/!gently/only-to-die
On Wed, Jul 18, 2018 at 3:04 PM Junio C Hamano wrote:
> Many topics have moved to 'master' and 'next' from 'next' to 'pu'
> respectively. As I needed to re-resolve semantic merge conflicts
> while reordering some topics (i.e. some that were merged earlier in
> 'pu' are left in 'pu' while another
I have a proposition for you, if you can maintain absolute confidentiality, get
back to me. More information await you in my next response to your email
message. Treat as very urgent.Barr Philip Twite
On Thu, Jul 19, 2018 at 12:05:00AM +0200, René Scheibe wrote:
> Code:
> -
> #!/bin/bash
>
> # setup repository
> git init --quiet repo
> cd repo
>
> echo '*.bin binary -delta' > .gitattributes
> git add .gitattributes
> git comm
On Thu, Jul 19, 2018 at 12:51 AM Elijah Newren wrote:
>
> I had a user report some poor behavior of 'git gc --aggressive' on a
> certain repo (which I sadly cannot share). Turns out that on this
> repo, this operation takes about 60% longer and produces a pack
> roughly twice the expected size.
On Wed, Jul 18, 2018 at 03:51:08PM -0700, Elijah Newren wrote:
> I had a user report some poor behavior of 'git gc --aggressive' on a
> certain repo (which I sadly cannot share). Turns out that on this
> repo, this operation takes about 60% longer and produces a pack
> roughly twice the expected
On Thu, Jul 19, 2018 at 07:41:03AM +0200, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 12:51 AM Elijah Newren wrote:
> >
> > I had a user report some poor behavior of 'git gc --aggressive' on a
> > certain repo (which I sadly cannot share). Turns out that on this
> > repo, this operation takes ab
On Thu, Jul 19, 2018 at 7:44 AM Jeff King wrote:
>
> On Wed, Jul 18, 2018 at 03:51:08PM -0700, Elijah Newren wrote:
>
> > I had a user report some poor behavior of 'git gc --aggressive' on a
> > certain repo (which I sadly cannot share). Turns out that on this
> > repo, this operation takes about
> * ot/ref-filter-object-info (2018-07-17) 5 commits
> - ref-filter: use oid_object_info() to get object
> - ref-filter: merge get_obj and get_object
> - ref-filter: initialize eaten variable
> - ref-filter: fill empty fields with empty values
> - ref-filter: add info_source to valid_atom
>
>
101 - 164 of 164 matches
Mail list logo
