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
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
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 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 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
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 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
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
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,
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
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
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
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
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
---
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 @@
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:
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
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
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
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
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:
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
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
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
>
> 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
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
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
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
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
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
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
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:
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
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: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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(_strategy));
>
> This line is causing build failures on 'pu' for certain setups:
>
yeah, will fix in a resend.
originally reported at
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
> > >
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
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
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
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
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
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
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
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
v6:
* fixed issues hinted at by Andrei, thanks! (range-diff below)
* incorporates the new config option, sent separately previously.
v5:
This is a resend of sb/diff-color-move-more
https://public-inbox.org/git/20180629001958.85143-1-sbel...@google.com/
that fixes an errornous squashing within the
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
On Wed, Jul 18, 2018 at 02:23:11PM +0200, Johannes Schindelin wrote:
> > Yeah, they're out of order in mutt's threaded display. And the
> > back-dating means there's a much higher chance of them getting blocked
> > as spam (e.g., some of the dates are from weeks ago).
> >
> > git-send-email uses
> > @@ -317,7 +317,7 @@ int for_each_fullref_in(const char *prefix, each_ref_fn
> > fn, void *cb_data,
> > int for_each_tag_ref(each_ref_fn fn, void *cb_data);
> > int for_each_branch_ref(each_ref_fn fn, void *cb_data);
> > int for_each_remote_ref(each_ref_fn fn, void *cb_data);
> > -int
On Wed, Jul 18, 2018 at 2:47 PM, Jeffrey Walton wrote:
> On Wed, Jul 18, 2018 at 1:49 PM, Junio C Hamano wrote:
>> Jeffrey Walton writes:
>> ...
>> diff --git a/Makefile b/Makefile
>> index 2ba24035f5..50138e85eb 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2086,7 +2086,7 @@
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 "inconsistency" a problem. The run
>
On Wed, Jul 18, 2018 at 1:49 PM, Junio C Hamano wrote:
> Jeffrey Walton writes:
> ...
> diff --git a/Makefile b/Makefile
> index 2ba24035f5..50138e85eb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2086,7 +2086,7 @@ $(SCRIPT_PERL_GEN): % : %.perl GIT-PERL-DEFINES
> GIT-PERL-HEADER
"Stefan Beller via GitGitGadget" writes:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Derrick Stolee
> ---
> builtin/replace.c | 8
> refs.c| 9 -
> refs.h| 2 +-
> replace-object.c | 5 +++--
> 4 files changed, 12
On Wed, Jul 18, 2018 at 11:25 AM Andrei Rybak wrote:
>
> On 2018-07-17 01:05, Stefan Beller wrote:
> >
> > This patch brings some challenges, related to the detection of blocks.
> > We need a white net the catch the possible moved lines, but then need to
>
> The s/white/wide/ was already
On 2018-07-17 01:05, Stefan Beller wrote:
>
> This patch brings some challenges, related to the detection of blocks.
> We need a white net the catch the possible moved lines, but then need to
The s/white/wide/ was already suggested by Brandon Williams in previous
iteration, but it seems this
Andrei Rybak writes:
> Add missing colon in two places to fix formatting of options.
>
> Signed-off-by: Andrei Rybak
> ---
>
> Done on top of maint.
>
> The earliest this patch applies is on top of commit aebd23506e ("Merge
> branch 'jk/ui-color-always-to-auto-maint' into
>
On 07/18, Stefan Beller wrote:
> > > Given the example above for "rebase-on-push" though
> > > it is better to first send the packfile (as that is assumed to
> > > take longer) and then send the ref updates, such that the
> > > rebasing could be faster and has no bottleneck.
> >
> > I don't really
Jeff King writes:
>> Perhaps we should exit with 2 (not 0) in that "previous error" case
>> by default, and then have a configuration knob to turn that 2 into 0
>> for those who cannot easily modify the calling script? That way, we
>> by default will *not* break those who have been paying
On Wed, Jul 18, 2018 at 8:08 PM Stefan Beller wrote:
> P.S.: another feature that just came to mind is localisation of error
> messages.
> But that is also easy to do with capabilities (the client sends a capability
> such as "preferred-i18n=DE" and the server may translate all its errors
> if
On Wed, Jul 18, 2018 at 10:45 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> > index 143acd9417e..8da7fed4e22 100644
> > --- a/Documentation/diff-options.txt
> > +++ b/Documentation/diff-options.txt
> > @@
> > Given the example above for "rebase-on-push" though
> > it is better to first send the packfile (as that is assumed to
> > take longer) and then send the ref updates, such that the
> > rebasing could be faster and has no bottleneck.
>
> I don't really follow this logic. I don't think it would
On Wed, Jul 18, 2018 at 7:46 PM Brandon Williams wrote:
>
> On 07/18, Duy Nguyen wrote:
> > On Wed, Jul 18, 2018 at 7:13 PM Brandon Williams wrote:
> > > > > > What I've got now is a rough design for a more flexible push, more
> > > > > > flexible because it allows for the server to do what it
Johannes Schindelin writes:
> Hi Olga,
>
> On Fri, 13 Jul 2018, Оля Тележная wrote:
>
>> 2018-07-09 11:27 GMT+03:00 Оля Тележная :
>> > Hello everyone,
>> > This is my new attempt to start using oid_object_info_extended() in
>> > ref-filter. You could look at previous one [1] [2] but it is not
On Wed, Jul 18, 2018 at 07:37:48PM +0200, Andrei Rybak wrote:
> Add missing colon in two places to fix formatting of options.
Thanks for catching.
> diff --git a/Documentation/git-for-each-ref.txt
> b/Documentation/git-for-each-ref.txt
> index 085d177d97..901faef1bf 100644
> ---
Jeffrey Walton writes:
> I'm trying to build Git 2.18 on Solaris 11.3 x86_64.
>
> $ gmake V=1
> rm -f git-add--interactive git-add--interactive+ && \
> sed -e '1{' \
> -e 's|#!.*perl|#!/usr/bin/perl|' \
> -e 'rGIT-PERL-HEADER' \
> -e 'G' \
> -e '}' \
>
On Wed, Jul 18, 2018 at 7:45 PM Jeff King wrote:
>
> On Wed, Jul 18, 2018 at 07:31:40PM +0200, Duy Nguyen wrote:
>
> > > Sort of an aside to the patch under discussion, but I think it may make
> > > sense for prune_shallow() to take a callback function for determining
> > > whether a commit is
On 07/18, Duy Nguyen wrote:
> On Wed, Jul 18, 2018 at 7:13 PM Brandon Williams wrote:
> > > > > What I've got now is a rough design for a more flexible push, more
> > > > > flexible because it allows for the server to do what it wants with the
> > > > > refs that are pushed and has the ability to
On Wed, Jul 18, 2018 at 07:31:40PM +0200, Duy Nguyen wrote:
> > Sort of an aside to the patch under discussion, but I think it may make
> > sense for prune_shallow() to take a callback function for determining
> > whether a commit is reachable.
> >
> > I have an old patch that teaches git-prune
Stefan Beller writes:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 143acd9417e..8da7fed4e22 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -294,8 +294,11 @@ dimmed_zebra::
>
> --color-moved-ws=::
> This
Add missing colon in two places to fix formatting of options.
Signed-off-by: Andrei Rybak
---
Done on top of maint.
The earliest this patch applies is on top of commit aebd23506e ("Merge
branch 'jk/ui-color-always-to-auto-maint' into
jk/ui-color-always-to-auto", 2017-10-04), one commit away
On Tue, Jul 17, 2018 at 9:41 PM Jeff King wrote:
> I slept on this to see if I could brainstorm any other ways.
>
> ..
>
> Sort of an aside to the patch under discussion, but I think it may make
> sense for prune_shallow() to take a callback function for determining
> whether a commit is
On Wed, Jul 18, 2018 at 03:11:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Yeah, I agree that deferring repeated gc's based on time is going to run
> > into pathological corner cases. OTOH, what we've found at GitHub is that
> > "gc --auto" is quite insufficient for scheduling maintenance
Phillip Wood writes:
>> The only consumer of a faulty author script written by the sequencer
>> is read_env_script() in sequencer.c which doesn't worry about
>> checking that quotes are paired.
>
> That's not quite true anymore, recently another consumer
> read_author_ident() was added which
On Wed, Jul 18, 2018 at 09:21:18AM -0700, Junio C Hamano wrote:
> > I still think that "repo" should probably stop respecting the exit code.
> > But that's no excuse for Git not to have a sensible exit code in the
> > first place.
>
> I am not yet convinced that this last step to exit with 0 is
On Wed, Jul 18, 2018 at 7:13 PM Brandon Williams wrote:
> > > > What I've got now is a rough design for a more flexible push, more
> > > > flexible because it allows for the server to do what it wants with the
> > > > refs that are pushed and has the ability to communicate back what was
> > > >
Phillip Wood writes:
>> (I think we had code to do so in "git am"
>> that was rewritten in C first).
>
> The code in builtin/am.c doesn't try to write valid posix shell (if
> one assumes it is the only consumer of the author script then it
> doesn't need to) which results in simpler code, but
On 07/18, Stefan Beller wrote:
> On Wed, Jul 18, 2018 at 6:31 AM Derrick Stolee wrote:
> >
> > On 7/17/2018 7:25 PM, Stefan Beller wrote:
> > > On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams
> > > wrote:
> > >> Signed-off-by: Brandon Williams
> > >> ---
> > >>
> > >> Since introducing
On 7/18/2018 1:01 PM, Junio C Hamano wrote:
No, fixing a tool that throws such a harder-to-read patch series in
reader's mailbox is *not* something I'd spend my primary focus on,
especially when many contributors are perfectly capable of sending
reasonably formatted series without using such a
On Tue, Jul 17, 2018 at 11:38 PM Frank Wolf wrote:
>
> Hi @ll,
>
> I hope I'm posting to the right group (not sure if it's Windows related) but
> I've got
> a weird problem using GIT:
>
> By accident I've tried to push a repository (containing an already
> commited but not yet pushed submodule
On 07/18, Derrick Stolee wrote:
> On 7/17/2018 7:25 PM, Stefan Beller wrote:
> > On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams wrote:
> > > Signed-off-by: Brandon Williams
> > > ---
> > >
> > > Since introducing protocol v2 and enabling fetch I've been thinking
> > > about what its inverse
On 07/17, Stefan Beller wrote:
> On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams wrote:
> >
> > Signed-off-by: Brandon Williams
> > ---
> >
> > Since introducing protocol v2 and enabling fetch I've been thinking
> > about what its inverse 'push' would look like. After talking with a
> > number
Hi Derrick,
> Overall, I think this is the right approach. The only problem is that
> you're missing a few 'the_repository' to 'r' replacements in the bodies
> of show_reference and register_replace_ref.
Thanks.
Originally I had another approach, which was to convert all
callbacks to take a
Henning Schild writes:
>> > + unset GIT_COMMITTER_EMAIL &&
>> > + git config user.email hasno...@nowhere.com &&
>> > + git config user.signingkey "" &&
>> > + test_must_fail git push --signed dst noop ff +noff &&
>>
>> This is OK for a test that is known to be always at the end, but
>>
1 - 100 of 165 matches
Mail list logo
