Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Jeff King writes: > All of the regressions people have actually _noticed_ stem from my > 136c8c8b8f in v2.14.2. So I think it is a viable option to try to go > back to the pre-v2.14.2 state. I.e.: > ... > That takes us back to the pre-regression state. The ancient bug from >

Re: [PATCH] revision: quit pruning diff more quickly when possible

Jeff King writes: > Here it is cleaned up and with a commit message. There's another case > that can be optimized, too: --remove-empty with an all-deletions commit. > That's probably even more obscure and pathological, but it was easy to > cover in the same breath. This one looks

Re: [PATCH] diff: alias -q to --quiet

Jeff King writes: > So there are two separate questions/tasks: > > 1. Should we remove the special handling of "-q" leftover from this > deprecation? I think the answer is yes. > > 2. Should we teach the diff machinery as a whole to treat "-q" as a > synonym for

Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

Junio C Hamano writes: >> Should we test that: >> >> git update-ref refs/heads/HEAD HEAD^ >> >> continues to work? > > Perhaps. Also we may want to make sure that "git branch -D HEAD" > still works as a way to recover from historical mistakes. The only difference is

Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

Jeff King writes: > On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote: > >> strbuf_check_branch_ref() is the central place where many codepaths >> see if a proposed name is suitable for the name of a branch. It was >> designed to allow us to get stricter than the

Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

Kevin Daudt writes: > On Thu, Oct 05, 2017 at 02:19:15PM +0200, Johannes Schindelin wrote: >> From: J Wyman >> [..] >> >> diff --git a/Documentation/git-for-each-ref.txt >> b/Documentation/git-for-each-ref.txt >> index 39f50bd53eb..22767025850 100644 >>

Re: [PATCH v3 07/10] connect: tell server that the client understands v1

On 10/10, Jonathan Tan wrote: > On Tue, 3 Oct 2017 13:15:04 -0700 > Brandon Williams wrote: > > > 2. ssh://, file:// > >Set 'GIT_PROTOCOL' environment variable with the desired protocol > >version. With the file:// transport, 'GIT_PROTOCOL' can be set > >

Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms

On 10/10, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > > Given some of this discussion though, maybe we want to change the > > semantics of 'protocol.version' so that both servers and clients respect > > it. As of right now, these patches have the server always allow > >

Re: [PATCH] Documentation: document Extra Parameters

On 10/10, Jonathan Tan wrote: > Document the server support for Extra Parameters, additional information > that the client can send in its first message to the server during a > Git client-server interaction. > > Signed-off-by: Jonathan Tan > --- > I noticed that

Re: [PATCH v3 05/10] upload-pack, receive-pack: introduce protocol version 1

On 10/10, Jonathan Tan wrote: > On Tue, 3 Oct 2017 13:15:02 -0700 > Brandon Williams wrote: > > > + switch (determine_protocol_version_server()) { > > + case protocol_v1: > > + if (advertise_refs || !stateless_rpc) > > + packet_write_fmt(1,

Re: [PATCH v3 04/10] daemon: recognize hidden request arguments

On 10/10, Jonathan Tan wrote: > On Tue, 3 Oct 2017 13:15:01 -0700 > Brandon Williams wrote: > > > /* > > * Read the host as supplied by the client connection. > > The return value is probably worth documenting. Something like "Returns > a pointer to the character *after*

Re: [PATCH] sequencer.c: unify error messages

Am 13.10.2017 um 19:51 schrieb Ralf Thielow: > When ftruncate() in rearrange_squash() fails, we write > that we couldn't finish the operation on the todo file. > It is more accurate to write that we couldn't truncate > as we do in other calls of ftruncate(). Would it make sense to factor out

[PATCH v2 2/2] diff: finish removal of deprecated -q option

Functionality was removed in c48f6816f0 but the cli option was not removed. Signed-off-by: Anthony Sottile --- builtin/diff-files.c | 2 -- builtin/diff.c | 2 -- diff.h | 4 +--- 3 files changed, 1 insertion(+), 7 deletions(-) diff --git

[PATCH v2 1/2] diff: alias -q to --quiet

Previously, `-q` was silently ignored: Before: $ git diff -q -- Documentation/; echo $? diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index a88c767..aa6e724 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -587,6 +587,7 @@

Re: [PATCH] diff: alias -q to --quiet

On Fri, Oct 13, 2017 at 09:44:15AM -0700, Anthony Sottile wrote: > Previously, `-q` was silently ignored: I'm not sure if is totally ignored. Normally if we have an unknown options we'd complain: $ git diff -x error: invalid option: -x but we don't with "-q". Why? In builtin/diff.c:471,

[PATCH] sequencer.c: unify error messages

When ftruncate() in rearrange_squash() fails, we write that we couldn't finish the operation on the todo file. It is more accurate to write that we couldn't truncate as we do in other calls of ftruncate(). While at there, remove a full stop in another error message. Signed-off-by: Ralf Thielow

Re: Can I remove multiple stashed states at a time?

On Fri, Oct 13, 2017 at 11:58:12AM +0900, 小川恭史 wrote: > I want to remove multiple stashed states at a time. > > But "git stash drop " removes only one stashed state at a time > and "git stash clear" remove all. > > Can I do that? There isn't a way to do it through "git stash", I don't think.

[PATCH 4/4] tag: respect color.ui config

Since 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), we expect that setting "color.ui" to "always" will enable color tag formats even without a tty. As that commit was built on top of 136c8c8b8f (color: check color.ui in git_default_config(), 2017-07-13) from

[PATCH 3/4] Revert "color: check color.ui in git_default_config()"

This reverts commit 136c8c8b8fa39f1315713248473dececf20f8fe7. That commit was trying to address a bug caused by 4c7f1819b3 (make color.ui default to 'auto', 2013-06-10), in which plumbing like diff-tree defaulted to "auto" color, but did not respect a "color.ui" directive to disable it. But it

[PATCH 2/4] Revert "t6006: drop "always" color config tests"

This reverts commit c5bdfe677cfab5b2e87771c35565d44d3198efda. That commit was done primarily to prepare for the weakening of "always" in 6be4595edb (color: make "always" the same as "auto" in config, 2017-10-03). But since we've now reverted 6be4595edb, there's no need for us to remove "-c

[PATCH 1/4] Revert "color: make "always" the same as "auto" in config"

This reverts commit 6be4595edb8e5b616c6e8b9fbc78b0f831fa2a87. That commit weakened the "always" setting of color config so that it acted as "auto". This was meant to solve regressions in v2.14.2 in which setting "color.ui=always" in the on-disk config broke scripts like add--interactive, because

[PATCH 0/4] peeling back color.ui=always hacks

On Fri, Oct 13, 2017 at 09:06:38AM -0400, Jeff King wrote: > > I think that it is too late, regardless of our release cycle. > > > > "Plumbing never looks at color.ui" implies that "plumbing must not > > get color.ui=auto from 4c7f1819", but given that 4c7f1819 is from > > 2013, I'd be surprised

[PATCH] diff: alias -q to --quiet

Previously, `-q` was silently ignored: Before: $ git diff -q -- Documentation/; echo $? diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index a88c767..aa6e724 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -587,6 +587,7 @@

Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

On Thu, Oct 05, 2017 at 02:19:15PM +0200, Johannes Schindelin wrote: > From: J Wyman > [..] > > diff --git a/Documentation/git-for-each-ref.txt > b/Documentation/git-for-each-ref.txt > index 39f50bd53eb..22767025850 100644 > --- a/Documentation/git-for-each-ref.txt > +++

Re: [PATCH] revision: quit pruning diff more quickly when possible

On Fri, Oct 13, 2017 at 11:37:50AM -0400, Derrick Stolee wrote: > Thanks, Peff. This patch looks good to me. > > I tried a few other things like adding a flag DIFF_OPT_HAS_ANY_CHANGE next > to DIFF_OPT_HAS_CHANGES that we could check in diff_can_quit_early() but it > had side-effects that broke

Re: [PATCH] revision: quit pruning diff more quickly when possible

On 10/13/2017 11:27 AM, Jeff King wrote: On Fri, Oct 13, 2017 at 10:26:46AM -0400, Jeff King wrote: On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote: This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is causing diff_can_quit_early() to return false. Due to

[PATCH] revision: quit pruning diff more quickly when possible

On Fri, Oct 13, 2017 at 10:26:46AM -0400, Jeff King wrote: > On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote: > > > This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is > > causing diff_can_quit_early() to return false. Due to the corner-case of the > > bug it

Re: git-clone causes out of memory

On 10/13/2017 10:26 AM, Jeff King wrote: On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote: This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is causing diff_can_quit_early() to return false. Due to the corner-case of the bug it seems it will not be a huge

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote: > This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is > causing diff_can_quit_early() to return false. Due to the corner-case of the > bug it seems it will not be a huge performance improvement in most cases. >

Re: git-clone causes out of memory

On 10/13/2017 10:20 AM, Jeff King wrote: On Fri, Oct 13, 2017 at 10:10:18AM -0400, Jeff King wrote: Hmm. So this patch makes it go fast: diff --git a/revision.c b/revision.c index d167223e69..b52ea4e9d8 100644 --- a/revision.c +++ b/revision.c @@ -409,7 +409,7 @@ static void

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 10:10:18AM -0400, Jeff King wrote: > Hmm. So this patch makes it go fast: > > diff --git a/revision.c b/revision.c > index d167223e69..b52ea4e9d8 100644 > --- a/revision.c > +++ b/revision.c > @@ -409,7 +409,7 @@ static void file_add_remove(struct diff_options *options, >

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 09:56:36AM -0400, Jeff King wrote: > On Fri, Oct 13, 2017 at 09:55:15AM -0400, Derrick Stolee wrote: > > > > We should be comparing an empty tree and d0/d0/d0/d0 (or however deep > > > your pathspec goes). We should be able to see immediately that the entry > > > is not

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 09:55:15AM -0400, Derrick Stolee wrote: > > We should be comparing an empty tree and d0/d0/d0/d0 (or however deep > > your pathspec goes). We should be able to see immediately that the entry > > is not present between the two and not bother descending. After all, > > we've

Re: git-clone causes out of memory

On 10/13/2017 9:50 AM, Jeff King wrote: On Fri, Oct 13, 2017 at 09:39:14AM -0400, Derrick Stolee wrote: Since I don't understand enough about the consumers to diff_tree_oid() (and the fact that the recursive behavior may be wanted in some cases), I think we can fix this in builtin/rev-list.c

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 09:39:14AM -0400, Derrick Stolee wrote: > Since I don't understand enough about the consumers to diff_tree_oid() (and > the fact that the recursive behavior may be wanted in some cases), I think > we can fix this in builtin/rev-list.c with this simple diff: > > --- > >

Re: git-clone causes out of memory

On 10/13/2017 9:15 AM, Derrick Stolee wrote: On 10/13/2017 8:44 AM, Jeff King wrote: On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote: On 13.10.2017 15:04, Junio C Hamano wrote: Christian Couder writes: Yeah, but perhaps Git could be smarter when

Re: git-clone causes out of memory

On 10/13/2017 8:44 AM, Jeff King wrote: On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote: On 13.10.2017 15:04, Junio C Hamano wrote: Christian Couder writes: Yeah, but perhaps Git could be smarter when rev-listing too and avoid processing files or

Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote: > strbuf_check_branch_ref() is the central place where many codepaths > see if a proposed name is suitable for the name of a branch. It was > designed to allow us to get stricter than the check_refname_format() > check used for

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

On Fri, Oct 13, 2017 at 12:37:57PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > OK. For the record, I'm not against scrapping this whole thing and > > trying to rollback to your "plumbing never looks at color.ui" proposal. > > It's quite late in the -rc cycle to do

Re: [ANNOUNCE] Git for Windows 2.14.2(3)

Johannes, On Thu, Oct 12, 2017 at 5:53 PM, Johannes Schindelin wrote: > Dear Git users, > > It is my pleasure to announce that Git for Windows 2.14.2(3) is available > from: > > https://git-for-windows.github.io/ > > Changes since Git for Windows v2.14.2(2)

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote: > On 13.10.2017 15:04, Junio C Hamano wrote: > > Christian Couder writes: > > > > > Yeah, but perhaps Git could be smarter when rev-listing too and avoid > > > processing files or directories it has already

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 07:06:03PM +0900, Mike Hommey wrote: > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: > > There's a gitbomb on github. It is undoubtedly creative and funny, but since > > this is a bug in git, I thought it'd be nice to report. The command: > > > > $ git

Re: git-clone causes out of memory

On 13.10.2017 15:04, Junio C Hamano wrote: Christian Couder writes: Yeah, but perhaps Git could be smarter when rev-listing too and avoid processing files or directories it has already seen? Aren't you suggesting to optimize for a wrong case? Anything that is

Re: git-clone causes out of memory

Christian Couder writes: > Yeah, but perhaps Git could be smarter when rev-listing too and avoid > processing files or directories it has already seen? Aren't you suggesting to optimize for a wrong case?

Re: [PATCH v2] Documentation/git-config.txt: reword missleading sentence

Moy Matthieu writes: >>> --path:: >>> - 'git-config' will expand leading '{tilde}' to the value of >>> + 'git config' will expand leading '{tilde}' to the value of >>> '$HOME', and '{tilde}user' to the home directory for the > > Didn't notice yesterday, but

Congratulations!

You won a donation funds of one million united states dollar. get back for more details

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

On Thu, Oct 05 2017, Johannes Sixt jotted: > Am 05.10.2017 um 21:33 schrieb Stefan Beller: >> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote: >>> +git-post(1) >>> +=== >>> + >>> +NAME >>> + >>> +git-post - Apply a commit on top of a branch that is not checked

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:37 PM, Mike Hommey wrote: > On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote: >> >> After cloning it with -n, there is the following "funny" situation: >> >> $ time git rev-list HEAD >> 7af99c9e7d4768fa681f4fe4ff61259794cf719b >>

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote: > On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote: > > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: > >> There's a gitbomb on github. It is undoubtedly creative and funny, but > >> since > >>

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote: > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: >> There's a gitbomb on github. It is undoubtedly creative and funny, but since >> this is a bug in git, I thought it'd be nice to report. The command: >> >>

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: > There's a gitbomb on github. It is undoubtedly creative and funny, but since > this is a bug in git, I thought it'd be nice to report. The command: > > $ git clone https://github.com/x0rz/ShadowBrokersFiles What fills memory is

git-clone causes out of memory

There's a gitbomb on github. It is undoubtedly creative and funny, but since this is a bug in git, I thought it'd be nice to report. The command: $ git clone https://github.com/x0rz/ShadowBrokersFiles quickly fills out the RAM (e.g. 4GB of free memory for me). To recover, call

Re: Enhancement request: git-push: Allow (configurable) default push-option

Updated patch and added tests: (feel free to modify Documentation) --- Subject: [PATCH] Added support for new configuration parameter push.pushOption builtin/push.c: add push.pushOption config Currently push options need to be given explicitly, via the command line as "git push --push-option".

Re: [PATCH v2] Documentation/git-config.txt: reword missleading sentence

Junio C Hamano writes: > second.pa...@gmail.com writes: > >> From: PAYRE NATHAN p1508475 > > Should I assume that the name/address on the last Signed-off-by: we > see below is what you want to be known as? As a part of school > work, I'd

Re: [PATCH 1/3] branch: streamline "attr_only" handling in validate_new_branchname()

On Fri, Oct 13, 2017 at 1:11 AM, Junio C Hamano wrote: > The function takes a parameter "attr_only" (which is a name that is > hard to reason about, which will be corrected soon) and skips some > checks when it is set. Reorganize the conditionals to make it move s/move/more/

Re: is there a truly compelling rationale for .git/info/exclude?

On Thu, 12 Oct 2017, Jeff King wrote: > On Fri, Oct 13, 2017 at 01:18:00AM +0200, Johannes Schindelin wrote: > > > [who I had to cull from the To:/Cc: headers, as my mailer consistently > > told me that there is no valid DNS record to route mail to > > rpj...@crashcourse.ca, which *is* weird.] >