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

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

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: 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: [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: 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

[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: [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

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 >> >

"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.

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 >

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 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: [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

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

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: 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: 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: [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 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

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: 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: 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 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: [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: [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 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 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 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] 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 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: [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

<    1   2