Re: [PATCH 1/3] path.c: fix uninitialized memory access

On Wed, Oct 04, 2017 at 01:47:29PM +0900, Junio C Hamano wrote: > Jonathan Nieder writes: > > > Jeff King wrote: > >> On Tue, Oct 03, 2017 at 03:45:01PM -0700, Jonathan Nieder wrote: > > > >>> In other words, an alternative fix would be > >>> > >>> if (*path == '.' &&

Re: [PATCH 3/3] sub-process: allocate argv on the heap

On Wed, Oct 04, 2017 at 01:59:31PM +0900, Junio C Hamano wrote: > > Perhaps this should become > > > > argv_array_push(>args, cmd); > > > > so that there is no new memory leak? > > Sounds like a good idea (if I am not grossly mistaken as to what is > being suggested). > > Here is what I am

Re: [PATCH 2/3] http-push: fix construction of hex value from path

On Wed, Oct 04, 2017 at 02:20:05PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > Jeff King writes: > > > >>> Moreover, this is in the webdav-based "dumb http" push code path, > >>> which I do not trust much at all. I wonder if we could retire it

Re: [PATCH 2/3] http-push: fix construction of hex value from path

Junio C Hamano writes: > Jeff King writes: > >>> Moreover, this is in the webdav-based "dumb http" push code path, >>> which I do not trust much at all. I wonder if we could retire it >>> completely (or at least provide an option to turn it off). >> >> I would

Re: [PATCH 3/3] sub-process: allocate argv on the heap

Am 04.10.2017 um 06:59 schrieb Junio C Hamano: Johannes Sixt writes: Am 03.10.2017 um 21:57 schrieb Thomas Gummerer: diff --git a/sub-process.c b/sub-process.c index 6dde5062be..4680af8193 100644 --- a/sub-process.c +++ b/sub-process.c @@ -77,7 +77,9 @@ int

Re: [PATCH v2] strbuf doc: reuse after strbuf_release is fine

On Tue, Oct 03, 2017 at 07:39:54PM -0700, Jonathan Nieder wrote: > > I think it's actually OK to use the string buffer after this function. > > It's just an empty string. > > > > Perhaps we should be more explicit: this releases any resources and > > resets to a pristine, empty state. I suspect

Re: [PATCH 2/3] merge-base: return fork-point outside reflog

Junio C Hamano writes: > Michael J Gruber writes: > >> I'm still trying to understand what the original intent was: If we >> abstract from the implementation (as we should, as you rightly >> emphasize) and talk about historical tips then we have to ask

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

On Fri, Sep 29, 2017 at 10:11 PM, Jonathan Tan wrote: > These patches are also available online: > https://github.com/jonathantanmy/git/commits/partialclone3 > > (I've announced it in another e-mail, but am now sending the patches to the > mailing list too.) > > Here's

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Tue, Oct 03, 2017 at 11:25:44AM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > Jonathan Nieder writes: > > > >> Yet another alternative would be to treat color.ui=always as a > >> deprecated synonym for color.ui=auto. I think that's my

Re: git add -p stops working when setting color.ui = always

On Mon, Oct 02, 2017 at 01:38:17PM +0300, Tsvi Mostovicz wrote: > Hi, > > When setting "color.ui = always" in the last few versions (not sure > exactly when this started, but definitely exists in 2.14.1 and > 2.14.2), git add -p stops working as expected. Instead of prompting > the user, it skips

Re: [PATCH v2] branch: change the error messages to be more meaningful

On Tue, 2017-10-03 at 09:21 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > I do not even recall what the patches did and if I thought what they > wanted to do made sense, I thought you did or may be I misinterpreted the following statement, On

[PATCH 0/3] fixes for running the test suite with --valgrind

I recently tried to run the git test suite with --valgrind. Unfortunately it didn't come back completely clean. This patch series fixes a bunch of these errors, although unfortunately not quite all of them yet. The remaining failures are in t0021.15 - This one is not actually valgrind

[PATCH 1/3] path.c: fix uninitialized memory access

In cleanup_path we're passing in a char array, run a memcmp on it, and run through it without ever checking if something is in the array in the first place. This can lead us to access uninitialized memory, for example in t5541-http-push-smart.sh test 7, when run under valgrind: ==4423==

[PATCH 3/3] sub-process: allocate argv on the heap

Currently the argv is only allocated on the stack, and then assigned to process->argv. When the start_subprocess function goes out of scope, the local argv variable is eliminated from the stack, but the pointer is still kept around in process->argv. Much later when we try to access the same

[PATCH 2/3] http-push: fix construction of hex value from path

The get_oid_hex_from_objpath takes care of creating a oid from a pathname. It does this by memcpy'ing the first two bytes of the path to the "hex" string, then skipping the '/', and then copying the rest of the path to the "hex" string. Currently it fails to increase the pointer to the hex

Re: [PATCH v8 00/12] Fast git status via a file system watcher

On 10/1/2017 4:24 AM, Junio C Hamano wrote: Ben Peart writes: I had accumulated the same set of changes with one addition of removing a duplicate "the" from a comment in the fsmonitor.h file: diff --git a/fsmonitor.h b/fsmonitor.h index 8eb6163455..0de644e01a

[PATCH v3 01/10] connect: in ref advertisement, shallows are last

From: Jonathan Tan Currently, get_remote_heads() parses the ref advertisement in one loop, allowing refs and shallow lines to intersperse, despite this not being allowed by the specification. Refactor get_remote_heads() to use two loops instead, enforcing that refs come

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

Teach upload-pack and receive-pack to understand and respond using protocol version 1, if requested. Protocol version 1 is simply the original and current protocol (what I'm calling version 0) with the addition of a single packet line, which precedes the ref advertisement, indicating the protocol

[PATCH v3 09/10] i5700: add interop test for protocol transition

Signed-off-by: Brandon Williams --- t/interop/i5700-protocol-transition.sh | 68 ++ 1 file changed, 68 insertions(+) create mode 100755 t/interop/i5700-protocol-transition.sh diff --git a/t/interop/i5700-protocol-transition.sh

[PATCH v3 06/10] connect: teach client to recognize v1 server response

Teach a client to recognize that a server understands protocol v1 by looking at the first pkt-line the server sends in response. This is done by looking for the response "version 1" send by upload-pack or receive-pack. Signed-off-by: Brandon Williams --- connect.c | 30

[PATCH] branch: reset instead of release a strbuf

Our documentation advises to not re-use a strbuf, after strbuf_release has been called on it. Use the proper reset instead. Signed-off-by: Stefan Beller --- Maybe one of the #leftoverbits is to remove the re-init call in release and see what breaks? (And then fixing up more

Re: [bug] git version 2.4.12 color.ui = always breaks git add -p

Hi Christian, Christian Rebischke wrote: > I played around with my gitconfig and I think I found a bug while doing > so. I set the following lines in my gitconfig: > > [color] > ui = always > > When I try to use `git add -p ` I don't see the 'Stage > this hunk'-dialog anymore. First I

contact my email (wang.jian...@yandex.com)

I intend to give you a portion of my wealth as a free-will financial donation to you, Respond to partake.contact my email (wang.jian...@yandex.com) Wang Jianlin Wanda Group

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

Teach the connection logic to tell a serve that it understands protocol v1. This is done in 2 different ways for the builtin transports. 1. git:// A normal request to git-daemon is structured as "command path/to/repo\0host=..\0" and due to a bug introduced in 49ba83fb6 (Add

Re: [PATCH 3/3] sub-process: allocate argv on the heap

On Tue, Oct 3, 2017 at 12:57 PM, Thomas Gummerer wrote: > Currently the argv is only allocated on the stack, and then assigned to > process->argv. When the start_subprocess function goes out of scope, > the local argv variable is eliminated from the stack, but the pointer

Project Proposal

Dear sir, I am Barrister Joseph Taylor, a legal Solicitor. I was the Personal Attorney and legal adviser to Mr. John ALBIN, a national of your country, who was an expatriate engineer to British Petroleum oil Company. My client, his wife, and their three children were involved in the ill fated

Re: "man git-config", "--list" option misleadingly refers to "config file" (singular)

On Tue, 3 Oct 2017, Jeff King wrote: > On Tue, Oct 03, 2017 at 06:34:34AM -0400, rpj...@crashcourse.ca wrote: > > > (i suppose that if i'm going to continue whining about stuff, i might > > as well clone the git source and start submitting patches.) > > Yes, please. :) > > > in "man

[PATCH v3 08/10] http: tell server that the client understands v1

Tell a server that protocol v1 can be used by sending the http header 'Git-Protocol' indicating this. Also teach the apache http server to pass through the 'Git-Protocol' header as an environment variable 'GIT_PROTOCOL'. Signed-off-by: Brandon Williams --- cache.h

[PATCH v3 10/10] ssh: introduce a 'simple' ssh variant

When using the 'ssh' transport, the '-o' option is used to specify an environment variable which should be set on the remote end. This allows git to send additional information when contacting the server, requesting the use of a different protocol version via the 'GIT_PROTOCOL' environment

[bug] git version 2.4.12 color.ui = always breaks git add -p

Hello everybody, I played around with my gitconfig and I think I found a bug while doing so. I set the following lines in my gitconfig: [color] ui = always When I try to use `git add -p ` I don't see the 'Stage this hunk'-dialog anymore. First I thought it's some other configuration but now

Re: [PATCH v3 10/10] ssh: introduce a 'simple' ssh variant

Hi, Brandon Williams wrote: > When using the 'ssh' transport, the '-o' option is used to specify an > environment variable which should be set on the remote end. This allows > git to send additional information when contacting the server, > requesting the use of a different protocol version via

Re: [PATCH] branch: reset instead of release a strbuf

Hi, Stefan Beller wrote: > Our documentation advises to not re-use a strbuf, after strbuf_release > has been called on it. Use the proper reset instead. I'm super surprised at this documentation. strbuf_release maintains the invariant that a strbuf is always usable (i.e., that we do not have

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

A normal request to git-daemon is structured as "command path/to/repo\0host=..\0" and due to a bug introduced in 49ba83fb6 (Add virtualization support to git-daemon, 2006-09-19) we aren't able to place any extra arguments (separated by NULs) besides the host otherwise the parsing of those

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

Create protocol.{c,h} and provide functions which future servers and clients can use to determine which protocol to use or is being used. Also introduce the 'GIT_PROTOCOL' environment variable which will be used to communicate a colon separated list of keys with optional values to a server.

[PATCH v3 00/10] protocol transition

Changes in v3: * added a new ssh variant 'simple' and update documentation to better reflect the command-line parameters passed to the ssh command. * updated various commit messages based on feedback. * tighten the wording for 'GIT_PROTOCOL' to indicate that both unknown keys and values

[PATCH v3 02/10] pkt-line: add packet_write function

Add a function which can be used to write the contents of an arbitrary buffer. This makes it easy to build up data in a buffer before writing the packet instead of formatting the entire contents of the packet using 'packet_write_fmt()'. Signed-off-by: Brandon Williams ---

Re: [PATCH 3/3] sub-process: allocate argv on the heap

Am 03.10.2017 um 21:57 schrieb Thomas Gummerer: diff --git a/sub-process.c b/sub-process.c index 6dde5062be..4680af8193 100644 --- a/sub-process.c +++ b/sub-process.c @@ -77,7 +77,9 @@ int subprocess_start(struct hashmap *hashmap, struct subprocess_entry *entry, co { int err;

[PATCH] test-list-objects: mark file-local symbols as static

Signed-off-by: Ramsay Jones --- Hi Derrick, If you need to re-roll your 'ds/find-unique-abbrev-optim' branch, could you please squash this into the relevant patch (commit 3792c78ba0, "test-list-objects: list a subset of object ids", 01-10-2017). Thanks! ATB,

Re: Line ending normalization doesn't work as expected

On 2017-10-03 19:23, Robert Dailey wrote: > On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen wrote: >> The short version is, that the instructions on Github are outdated. >> This is the official procedure (since 2016, Git v2.12 or so) >> But it should work even with older

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Jonathan Nieder writes: > +Alternatives considered > +--- > +Upgrading everyone working on a particular project on a flag day > + > ... > +Using hash functions in parallel >

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: >> $ git rm -r --cached . && git add . > > (Both should work) > > To be honest, from the documentation, I can't figure out the difference > between > $ git read-tree --empty > and > $ git rm -r --cached . > > Does anybody remember the discussion, why

Re: [PATCH v8 00/12] Fast git status via a file system watcher

Ben Peart writes: > Well, rats. I found one more issue that applies to two of the > commits. Can you squash this in as well or do you want it in some > other form? Rats indeed. Let's go incremental as promised, perhaps like this (but please supply a better description if

Re: [PATCH] branch: reset instead of release a strbuf

Jeff King writes: >> /** >> * Release a string buffer and the memory it used. You should not use the >> - * string buffer after using this function, unless you initialize it again. >> + * string buffer after using this function. >> */ >> extern void strbuf_release(struct

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

On 03/10/17 04:51, Junio C Hamano wrote: > Ramsay Jones writes: > >> On 02/10/17 14:44, Pranit Bauva wrote: >> [snip] >>> ... >> Yes, I also meant to tidy that up by removing some, now >> redundant, initialisation later in that function. >> >> Note, that wasn't the

Re: Git for Windows: mingw.c's strange usage of creation time as ctime?

+git-for-windows Hi Marc, Marc Strapetz wrote: > compat/mingw.c assigns the Windows file creation time [1] to Git's > ctime fields at line 591 and at line 705: > > buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime)); > > ftCreationTime > ftLastWriteTime is actually possible after copying

[PATCH v2] strbuf doc: reuse after strbuf_release is fine

strbuf_release leaves the strbuf in a valid, initialized state, so there is no need to call strbuf_init after it. Moreover, this is not likely to change in the future: strbuf_release leaving the strbuf in a valid state has been easy to maintain and has been very helpful for Git's robustness and

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jeff King writes: > Here's what I came up with on the "color.ui=always is nonsense that we > should not offer" front. The number of patches may be a little daunting, > but most of them are just removing cases of "git -c color.ui=always" > from the tests. > > [01/12]:

Cash Statement of Account 10/03/2017

Kindly find attached today's cash payments statement of account. 10/3/2017 Reems Exchange Company SOA-03-10-2017.pdf Description: SOA-03-10-2017.pdf

Re: [PATCH] branch: reset instead of release a strbuf

Hi, Stefan Beller wrote: > Our documentation advises to not re-use a strbuf, after strbuf_release > has been called on it. Use the proper reset instead. > > Reviewed-by: Jonathan Nieder This is indeed Reviewed-by: Jonathan Nieder Thank you. >

[PATCH] branch: reset instead of release a strbuf

Our documentation advises to not re-use a strbuf, after strbuf_release has been called on it. Use the proper reset instead. Currently 'strbuf_release' releases and re-initializes the strbuf, so it is safe, but slow. 'strbuf_reset' only resets the internal length variable, such that this could

Re: [PATCH 1/3] path.c: fix uninitialized memory access

Hi, Thomas Gummerer wrote: > In cleanup_path we're passing in a char array, run a memcmp on it, and > run through it without ever checking if something is in the array in the > first place. This can lead us to access uninitialized memory, for > example in t5541-http-push-smart.sh test 7, when

Re: [PATCH 2/3] http-push: fix construction of hex value from path

Hi, Thomas Gummerer wrote: > The get_oid_hex_from_objpath takes care of creating a oid from a > pathname. It does this by memcpy'ing the first two bytes of the path to > the "hex" string, then skipping the '/', and then copying the rest of the > path to the "hex" string. Currently it fails to

Re: [PATCH] test-stringlist: avoid buffer underrun when sorting nothing

René Scharfe wrote: > Check if the strbuf containing data to sort is empty before attempting > to trim a trailing newline character. > > Signed-off-by: Rene Scharfe > --- > t/helper/test-string-list.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for fixing it.

Re: "man git-config", "--list" option misleadingly refers to "config file" (singular)

On Tue, Oct 03, 2017 at 04:54:32PM -0400, Robert P. J. Day wrote: > > It does that by default, or it lists the contents of a specific file > > if given (either by --file, or with --system, --global, or --local). > > > > So I agree it's not quite accurate, but you probably want some > > phrasing

Re: [PATCH 1/3] path.c: fix uninitialized memory access

On Tue, Oct 03, 2017 at 03:45:01PM -0700, Jonathan Nieder wrote: > When I first read the above, I thought it was going to be about a > NUL-terminated string that was missing a NUL. But in fact, the issue > is that strlen(path) can be < 2. > > In other words, an alternative fix would be > >

"man git-config", "--list" option misleadingly refers to "config file" (singular)

(i suppose that if i'm going to continue whining about stuff, i might as well clone the git source and start submitting patches.) in "man git-config": -l --list List all variables set in config file, along with their values.

[PATCH] run-command.c: add hint when hook is not executable

--- Documentation/config.txt | 2 ++ advice.c | 2 ++ advice.h | 1 + contrib/completion/git-completion.bash | 1 + run-command.c | 4 5 files changed, 10 insertions(+) diff --git

Re: Security of .git/config and .git/hooks

Hi, On Tue, Oct 3, 2017 at 1:45 AM, Jonathan Nieder wrote: > Proposed fix: because of case (1), I would like a way to tell Git to > stop trusting any files in .git. That is: > > 1. Introduce a (configurable) list of "safe" configuration items that > can be set in

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

On 10/3/2017 6:49 AM, Junio C Hamano wrote: Derrick Stolee writes: p0008.1: find_unique_abbrev() for existing objects -- For 10 repeated tests, each checking 100,000 known objects, we find the following results when

Re: What means "git config bla ~/"?

"Junio C Hamano" writes: > Jonathan Nieder writes: > >>> what's with that "git config bla ~/"? is this some config keyword >>> or something? >> ... >> >> I agree with you that it is less clear than it could be. Ideas for >> clarifying it? > > Yeah, if

Re: Security of .git/config and .git/hooks

On Mon, Oct 02, 2017 at 04:45:17PM -0700, Jonathan Nieder wrote: > This topic has been mentioned on this mailing list before but I had > trouble finding a relevant reference. Links welcome. There were discussions long ago related to the upload-pack hook. One of the proposed fixes was checking

Re: [PATCH] tag: avoid NULL pointer arithmetic

> lookup_blob() etc. can return NULL if the referenced object isn't of the > expected type. In theory it's wrong to reference the object member in > that case. In practice it's OK because it's located at offset 0 for all > types, so the pointer arithmetic (NULL + 0) is optimized out by the >

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jeff King writes: > On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Note that I'm arguing that it's a foot-gun even without scripts in the >> > picture at all. Forget about plumbing versus porcelain. If you set >> >

Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r

Derrick Stolee writes: > p0008.1: find_unique_abbrev() for existing objects > -- > > For 10 repeated tests, each checking 100,000 known objects, we find the > following results when running in a Linux VM: > > | | Pack

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Tue, Oct 03, 2017 at 04:10:12PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I'd prefer not to revert. I think setting any of the color config to > > "always" in an on-disk file is basically a broken config. It was > > exacerbated by 4c7f1819b, but it was already

Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h

On Mon, Oct 02, 2017 at 12:37:53PM +0300, Оля Тележная wrote: > >> Simplify mru.[ch] and related code by reusing the double-linked list > >> implementation from list.h instead of a custom one. > >> This commit is an intermediate step. Our final goal is to get rid of > >> mru.[ch] at all and

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Tue, Oct 03, 2017 at 05:34:40PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I agree it's not quite the same thing, and I agree the problem was made > > much worse by 4c7f1819b. But I still think color.ui=always is > > inherently a foot-gun, and in either case it is

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Note that I'm arguing that it's a foot-gun even without scripts in the > > picture at all. Forget about plumbing versus porcelain. If you set > > color.ui to "always", you're going to get

Re: [PATCH v2] oidmap: map with OID as key

On Mon, Oct 02, 2017 at 04:48:48PM -0700, Brandon Williams wrote: > > Some replies to v1 [1] [2] seem to indicate that simpler non-duplicated > > code should be preferred over optimizing away the storage of the 4-byte > > hash code, and I have no objection to that, so I have updated this code > >

Re: [PATCH v6 00/40] Add initial experimental external ODB support

On Mon, Oct 2, 2017 at 4:18 PM, Ben Peart wrote: > > On 9/16/2017 4:06 AM, Christian Couder wrote: > > - Patch 1/40 is a small code cleanup that I already sent to the >> >>mailing list but may be removed in the end due to ongoing work >>on "git clone". >>

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

On Tue, Oct 03, 2017 at 03:24:41PM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Since that's the only thing I noticed, let's hold off on a reroll for > > the moment to see if there are any more comments (and I won't be > > surprised if Junio just picks it up with the

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jeff King writes: > I agree it's not quite the same thing, and I agree the problem was made > much worse by 4c7f1819b. But I still think color.ui=always is > inherently a foot-gun, and in either case it is the user that sets it > that is harmed (and they are the ones who have the

Re: [PATCH v6 09/40] Add initial external odb support

On Fri, Sep 29, 2017 at 10:36 PM, Jonathan Tan wrote: > On Wed, 27 Sep 2017 18:46:30 +0200 > Christian Couder wrote: >> I don't think single-shot processes would be a huge burden, because >> the code is simpler, and because for example for

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

There is a need to pass predefined push-option during "git push" without need to specify it explicitly. In another words we need to have a new "git config" variable to specify string that will be automatically passed as "--push-option" when pushing to remote. Something like the following: git

Re: [PATCH 00/11] various lockfile-leaks and -fixes

Martin Ågren writes: > On 2 October 2017 at 08:30, Junio C Hamano wrote: > ... >> Thanks, both. Let's merge this to 'next' soonish. > > Thanks both of you for your comments. Based on them, I have made the > following notes: > ... > Especially 9-11

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

Jeff King writes: > Since that's the only thing I noticed, let's hold off on a reroll for > the moment to see if there are any more comments (and I won't be > surprised if Junio just picks it up with the tweak, but we'll see). > > Please do make sure that "make test" runs clean

Re: [PATCH] builtin/: add UNLEAKs

Martin Ågren writes: >> Seeing hunks like this makes me happy with the UNLEAK() solution. It >> would have been a real pain to do this via actual freeing. > > Yes, I was very happy to have it handy. :-) OK, let's merge this to 'next', then.

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

Jeff King writes: > Out of curiosity, do you frequently test with GETTEXT_POISON, or did you > just guess at a potential problem after reading the tests? Proper use > of test_i18ncmp is definitely something we ought to be looking for > during review, but I confess it's something

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jeff King writes: > I'd prefer not to revert. I think setting any of the color config to > "always" in an on-disk file is basically a broken config. It was > exacerbated by 4c7f1819b, but it was already broken for scripts that > call "git log" or "git diff", or even just something

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

Christian Couder writes: > Could you give a bit more details about the use cases this is designed for? > It seems that when people review my work they want a lot of details > about the use cases, so I guess they would also be interesting in > getting this kind of

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Tue, Oct 03, 2017 at 02:15:15AM -0400, Jeff King wrote: > The two reasonable paths forward to me are: > > 1. Do nothing. Putting "color.ui = always" in your on-disk config is a > bad idea, and the right fix is to stop doing it. > > 2. Make "always" a synonym for "auto". This has the

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jeff King writes: > Note that I'm arguing that it's a foot-gun even without scripts in the > picture at all. Forget about plumbing versus porcelain. If you set > color.ui to "always", you're going to get unexpected and confusing > results from time to time. Really? I would

Re: Updated to v2.14.2 on macOS; git add --patch broken

I also don't remember why I set it, and as such I removed it. A helpful hint as to a bad config option would've been great. Something along the lines of "The use of color.ui = always is not recommended", with a flag allowing you to disable said warning. Thanks, Tsvi Tsvi Mostovicz

Re: [PATCH v4] technical doc: add a design doc for hash function transition

On Tue, Oct 03, 2017 at 02:40:26PM +0900, Junio C Hamano wrote: > Jonathan Nieder writes: ... > > +Meaning of signatures > > +~ > > +The signed payload for signed commits and tags does not explicitly > > +name the hash used to identify objects. If some day

[PATCH 03/12] t4015: use --color with --color-moved

The tests for --color-moved write their output to a file, but doing so suppresses color output under "auto". Right now this is solved by running the whole script under "color.diff=always". In preparation for the behavior of "always" changing, let's explicitly enable color. Signed-off-by: Jeff

[PATCH 04/12] t3701: use test-terminal to collect color output

When testing whether "add -p" can generate colors, we set color.ui to "always". This isn't a very good test, as in the real-world a user typically has "auto" coupled with stdout going to a terminal (and it's plausible that this could mask a real bug in add--interactive if we depend on plumbing's

[PATCH 06/12] t7502: use diff.noprefix for --verbose test

To check that "status -v" respects diff config, we set "color.diff" and look at the output of "status". We could equally well use any diff config. Since color output depends on a lot of other factors (like whether stdout is a tty, and how we interpret "always"), let's use a more mundane option.

[PATCH 08/12] t3203: drop "always" color test

In preparation for the behavior of "always" changing to match "auto", we can simply drop this test. We already check other forms (like "--color") independently. Signed-off-by: Jeff King --- t/t3203-branch-output.sh | 6 -- 1 file changed, 6 deletions(-) diff --git

[PATCH 05/12] t7508: use test_terminal for color output

This script tests the output of status with various formats when color is enabled. It uses the "always" setting so that the output is valid even though we capture it in a file. Using test_terminal gives us a more realistic environment, and prepares us for the behavior of "always" changing.

[PATCH 11/12] provide --color option for all ref-filter users

When ref-filter learned about want_color() in 11b087adfd (ref-filter: consult want_color() before emitting colors, 2017-07-13), it became useful to be able to turn colors off and on for specific commands. For git-branch, you can do so with --color/--no-color. But for git-for-each-ref and git-tag,

[PATCH 12/12] color: make "always" the same as "auto" in config

It can be handy to use `--color=always` (or it's synonym `--color`) on the command-line to convince a command to produce color even if it's stdout isn't going to the terminal or a pager. What's less clear is whether it makes sense to set config variables like color.ui to `always`. For a one-shot

[PATCH] fsck: check results of lookup_blob() and lookup_tree() for NULL

Am 03.10.2017 um 14:51 schrieb René Scharfe: > Am 03.10.2017 um 12:22 schrieb SZEDER Gábor: >> Furthermore, fsck.c:fsck_walk_tree() does the same "immediately >> reference the object member in lookup_blob()'s and lookup_tree()'s >> return value" thing. I think those should receive the same

Re: "man git-config", "--list" option misleadingly refers to "config file" (singular)

On Tue, Oct 03, 2017 at 06:34:34AM -0400, rpj...@crashcourse.ca wrote: > (i suppose that if i'm going to continue whining about stuff, i might > as well clone the git source and start submitting patches.) Yes, please. :) > in "man git-config": > > -l > --list > List all

Re: [PATCH] tag: avoid NULL pointer arithmetic

Am 03.10.2017 um 12:22 schrieb SZEDER Gábor: >> lookup_blob() etc. can return NULL if the referenced object isn't of the >> expected type. In theory it's wrong to reference the object member in >> that case. In practice it's OK because it's located at offset 0 for all >> types, so the pointer

I am waiting for your Reply

Dear Friend, Good Day. I know this message might meet you in utmost surprise; however, it's just my urgent need for a foreign partner that made me to contact you for this mutual benefiting business when searching for a good and reliable and trust worthy person. I got your contact email address

[PATCH 02/12] t4015: prefer --color to -c color.diff=always

t4015 contains many color-related tests which need to override the "is stdout a tty" check. They do so by setting the color.diff config, but we can accomplish the same with the --color option. Besides being shorter to type, switching will prepare us for upcoming changes to "always" when see it in

Re: Updated to v2.14.2 on macOS; git add --patch broken

On Tue, Oct 03, 2017 at 07:38:24PM +0900, Junio C Hamano wrote: > That's an argument to say color.ui=always is not a useful thing to > use and Git is wrong to offer such a nonsense option. I agree with > both of them. > > But it is a different matter that plumbing commands are now doing > the

[PATCH 01/12] test-terminal: set TERM=vt100

The point of the test-terminal script is to simulate in the test scripts an environment where output is going to a real terminal. But since test-lib.sh also sets TERM=dumb, the simulation isn't very realistic. The color code will skip auto-coloring for TERM=dumb, leading to us liberally

[PATCH 09/12] t7301: use test_terminal to check color

This test wants to confirm that "clean -i" shows color output. Using test_terminal gives us a more realistic environment than "color.ui=always", and prepares us for the behavior of "always" changing in a future patch. Signed-off-by: Jeff King --- t/t7301-clean-interactive.sh | 5

[PATCH 07/12] t6006: drop "always" color config tests

We test the %C() format placeholders with a variety of color-inducing options, including "--color" and "-c color.ui=always". In preparation for the behavior of "always" changing, we need to do something with those "always" tests. We can drop ones that expect "always" to turn on color even to a

  1   2   >