Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

>> This was actually discussed in a separate thread [1] some time ago with >> patches proposed by Thandesha and me. >> I haven't yet got time to cook a final patch, which addresses both >> Thandesha's and mine use-cases though, >> so this wasn't submitted to Junio yet. >> In the meantime, I

BUG: rev-parse segfault with invalid input

Hi, Certain invalid input causes git rev-parse to crash rather than return a 'fatal: ambiguous argument ...' error. This was reported against the Fedora git package: https://bugzilla.redhat.com/1581678 Simple reproduction recipe and analysis, from the bug: $ git init Initialized

Re: BUG: rev-parse segfault with invalid input

On Wed, May 23, 2018 at 12:52 PM, Todd Zullinger wrote: > Hi, > > Certain invalid input causes git rev-parse to crash rather > than return a 'fatal: ambiguous argument ...' error. > > This was reported against the Fedora git package: > > https://bugzilla.redhat.com/1581678 > >

Re: BUG: rev-parse segfault with invalid input

Hi, Elijah Newren wrote: > Thanks for the detailed report. This apparently goes back to > git-1.6.0 with commit 2122f8b963d4 ("rev-parse: Add support for the ^! > and ^@ syntax", 2008-07-26). We aren't checking that the commit from > lookup_commit_reference() is non-NULL before proceeding.

[PATCH 1/2] t6101: add a test for rev-parse $garbage^@

Reported by Florian Weimer and Todd Zullinger. Signed-off-by: Elijah Newren --- t/t6101-rev-parse-parents.sh | 4 1 file changed, 4 insertions(+) diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh index 8c617981a3..7b1b2dbdf2 100755 ---

[PATCH 2/2] rev-parse: verify that commit looked up is not NULL

In commit 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", 2008-07-26), try_parent_shorthands() was introduced to parse the special ^! and ^@ syntax. However, it did not check the commit returned from lookup_commit_reference() before proceeding to use it. If it is NULL, bail

Re: [PATCH 1/2] t6101: add a test for rev-parse $garbage^@

On Wed, May 23, 2018 at 01:46:12PM -0700, Elijah Newren wrote: > diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh > index 8c617981a3..7b1b2dbdf2 100755 > --- a/t/t6101-rev-parse-parents.sh > +++ b/t/t6101-rev-parse-parents.sh > @@ -214,4 +214,8 @@ test_expect_success

Re: [PATCH 2/2] rev-parse: verify that commit looked up is not NULL

On Wed, May 23, 2018 at 01:46:13PM -0700, Elijah Newren wrote: > In commit 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", > 2008-07-26), try_parent_shorthands() was introduced to parse the special > ^! and ^@ syntax. However, it did not check the commit returned from >

[PATCHv5 1/1] git-p4: add unshelve command

This can be used to "unshelve" a shelved P4 commit into a git commit. For example: $ git p4 unshelve 12345 The resulting commit ends up in the branch: refs/remotes/p4/unshelved/12345 If that branch already exists, it is renamed - for example the above branch would be saved as

[PATCHv5 0/1] git-p4: unshelve: fix problem with newer p4d

This is v5 of my git-p4 unshelve patch. It fixes a problem found by SZEDER Gábor with newer versions of Perforce (2016 vs 2015). Luke Diamand (1): git-p4: add unshelve command Documentation/git-p4.txt | 32 ++ git-p4.py| 215 ---

lening

Goede dag, We zijn Funding Trusts Finance verstrekt leningen per postadvertentie. Wij bieden verschillende soorten leningen of projectleningen (korte en lange termijnleningen, persoonlijke leningen, leningen aan bedrijven enz.) Met een rentetarief van 3%. We verstrekken leningen

Re: should config options be treated as case-sensitive?

On Wed, 23 May 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > The issues you note about the docs using foo.barbaz instead of > > foo.barBaz should be fixed, but as noted in the "Syntax" section > > of "git-config" we already document that the config keys

Re: [PATCH v2 0/3] config: free resources of `struct config_store_data`

On Sun, May 20, 2018 at 6:42 AM, Martin Ågren wrote: > On 14 May 2018 at 05:03, Eric Sunshine wrote: >> On Sun, May 13, 2018 at 5:58 AM, Martin Ågren wrote: >>> How about the following two patches as patches 2/3 and 3/3? I

Re: should config options be treated as case-sensitive?

On Wed, 23 May 2018, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > >> If the documention does not make it clear, then we have > >> documentation bug ... > > > > personally, i would add a short, really emphatic note at the top of > > "man git-config" pointing

lening

Goede dag, We zijn Funding Trusts Finance verstrekt leningen per postadvertentie. Wij bieden verschillende soorten leningen of projectleningen (korte en lange termijnleningen, persoonlijke leningen, leningen aan bedrijven enz.) Met een rentetarief van 3%. We verstrekken leningen

Re: should config options be treated as case-sensitive?

"Robert P. J. Day" writes: >> If the documention does not make it clear, then we have >> documentation bug ... > > personally, i would add a short, really emphatic note at the top of > "man git-config" pointing this out -- i wouldn't require people to > read all the way

Re: [PATCH v2 3/3] config: let `config_store_data_clear()` handle `key`

On Sun, May 20, 2018 at 6:42 AM, Martin Ågren wrote: > Instead of remembering to free `key` in each code path, let > `config_store_data_clear()` handle that. > > We still need to free it before replacing it, though. Move that freeing > closer to the replacing to be safe.

Re: which files are "known to git"?

On Mon, 21 May 2018, Jonathan Nieder wrote: > Robert P. J. Day wrote: > > On Mon, 21 May 2018, Elijah Newren wrote: > > >> Hi Robert, > >> > >> I had always assumed prior to your email that 'known to Git' > >> meant 'tracked' or 'recorded in the index'... > > > > i *know* i've been in this

Re: [PATCH v2] t: make many tests depend less on the refs being files

Christian Couder writes: > The internals of the loose refs backend are still tested in > t1400-update-ref.sh, whereas the tests changed in this patch focus > on testing other aspects. > > This patch just takes care of many low hanging fruits. It does not > try to

Re: git push => git: 'credential-winstore' is not a git command.

On Sun, May 20, 2018 at 10:17:54AM -0500, Chris wrote: > git config --global --unset credential.helper > > > This did help me, because previously Git was trying to authenticate me > with the Microsoft account I use to log into my Windows, which is > unrelated to the account I need to use to

Re: [PATCH v3 2/7] block alloc: add lifecycle APIs for cache_entry structs

Jameson Miller writes: > Add an API around managing the lifetime of cache_entry > structs. Abstracting memory management details behind an API will > allow for alternative memory management strategies without affecting > all the call sites. This commit does not change how

Re: [RFC PATCH v3 1/2] Implement --first-parent for git rev-list --bisect

Tiago Botelho writes: > -static int count_interesting_parents(struct commit *commit) > +static int count_interesting_parents(struct commit *commit, unsigned > bisect_flags) > { > struct commit_list *p; > int count; > > for (count = 0, p =

Re: [PATCH v3 0/7] allocate cache entries from memory pool

Jameson Miller writes: > Changes from V2: > > - Tweak logic of finding available memory block for memory > allocation > > - Only search head block Hmph. Is that because we generally do not free() a lot so once a block is filled, there is not

Re: [RFC PATCH v3 2/2] Add tests for rev-list --bisect* --first-parent

Tiago Botelho writes: > Subject: [RFC PATCH v3 1/2] Implement --first-parent for git rev-list --bisect > Subject: [RFC PATCH v3 2/2] Add tests for rev-list --bisect* --first-parent perhaps bisect: teach "git rev-list --bisect" to work with "--first-parent"

Re: [PATCH] Add initial support for pax extended attributes

Jeff King writes: > I do think we'd fail to notice the truncation, which isn't ideal. But it > looks like the rest of the script suffers from the same issue. > > If anybody cares, it might not be too hard to wrap all of the 512-byte > read calls into a helper that dies on bogus

Re: git push => git: 'credential-winstore' is not a git command.

Thanks, Peff. I should have thought about the configuration hierarchy... This evening I need to do some trial-and-error with the three credential entries that found. Want what you have, Chris On Wed, May 23, 2018 at 1:16 AM, Jeff King wrote: > On Sun, May 20, 2018 at 10:17:54AM

[RFC PATCH v3 1/2] Implement --first-parent for git rev-list --bisect

This will enable users to implement bisecting on first parents which can be useful for when the commits from a feature branch that we want to merge are not always tested. Signed-off-by: Tiago Botelho --- bisect.c | 53

[RFC PATCH v3 2/2] Add tests for rev-list --bisect* --first-parent

--- t/t6002-rev-list-bisect.sh | 39 +++ 1 file changed, 39 insertions(+) diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh index a66140803..977c82157 100755 --- a/t/t6002-rev-list-bisect.sh +++ b/t/t6002-rev-list-bisect.sh @@ -263,4 +263,43

From: Mr James Tan (Urgent & Confidential)

-- From: Mr James Tan (Urgent & Confidential) Good Day, Please Read. My name is Mr. James Tan, I am the Bill and Exchange manager here in Bank of Africa (BOA) Lome/Togo.West-Africa. I have a business proposal in the tune of $9.7m, (Nine Million Seven hundred Thousand only) after the successful

Re: should config options be treated as case-sensitive?

"Robert P. J. Day" writes: >> Unfortunately, that line of thinking leads us to madness, as you are >> exhibiting the typical symptom of "my today's immediate itch is the >> most important one in the world"-itis > > fair enough, point taken. FWIW, everybody suffers

[PATCHv6 0/1] git-p4: unshelve

This just removes the verbose print change, which will end up causing conflicts later since it's also being fixed in another commit. Discussed here: https://public-inbox.org/git/byapr08mb38455afe85ae6b04eb31ef92da...@byapr08mb3845.namprd08.prod.outlook.com/ Luke Diamand (1): git-p4: add

[PATCHv6 1/1] git-p4: add unshelve command

This can be used to "unshelve" a shelved P4 commit into a git commit. For example: $ git p4 unshelve 12345 The resulting commit ends up in the branch: refs/remotes/p4/unshelved/12345 If that branch already exists, it is renamed - for example the above branch would be saved as

Re: [PATCH 2/2] rev-parse: verify that commit looked up is not NULL

Elijah Newren wrote: > In commit 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", > 2008-07-26), try_parent_shorthands() was introduced to parse the special > ^! and ^@ syntax. However, it did not check the commit returned from > lookup_commit_reference() before proceeding to use

[PATCH v2 0/1] import-tars: read overlong names from pax extended header

From: Pedro Alvarez Piedehierro Hello! In this version I've trimmed and improved the commit message as suggested. Regarding the error handling, as Jeff mentioned, could be improved in general in the entire script. But I guess I could do it if needed to get this patch

[PATCH v2 1/1] import-tars: read overlong names from pax extended header

From: Pedro Alvarez Piedehierro Importing gcc tarballs[1] with import-tars script (in contrib) fails when hitting a pax extended header. Make sure we always read the extended attributes from the pax entries, and store the 'path' value if found to be used in the next ustar

What's cooking in git.git (May 2018, #03; Wed, 23)

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. You can find the changes

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH 2/2] rev-parse: verify that commit looked up is not NULL

I wrote: > Thanks. This fixes the segfault. While I was testing this, > I wondered if the following cases should differ: Nevermind me. Jeff beat me to a reply and included much more useful details about why this occurs and suggestions for fixing it. :) > # f*40 > $ ./git-rev-parse

[PATCH v3 2/7] block alloc: add lifecycle APIs for cache_entry structs

Add an API around managing the lifetime of cache_entry structs. Abstracting memory management details behind an API will allow for alternative memory management strategies without affecting all the call sites. This commit does not change how memory is allocated / freed. A later commit in this

[PATCH v3 1/7] read-cache: teach refresh_cache_entry() to take istate

Refactor refresh_cache_entry() to work on a specific index, instead of implicitly using the_index. This is in preparation for making the make_cache_entry function work on a specific index. Signed-off-by: Jameson Miller --- cache.h | 2 +- merge-recursive.c | 2 +-

[PATCH v3 0/7] allocate cache entries from memory pool

Changes from V2: - Tweak logic of finding available memory block for memory allocation - Only search head block - Tweaked handling of large memory allocations. - Large blocks now tracked in same manner as "regular"

[PATCH v3 3/7] mem-pool: only search head block for available space

Instead of searching all memory blocks for available space to fulfill a memory request, only search the head block. If the head block does not have space, assume that previous block would most likely not be able to fulfill request either. This could potentially lead to more memory fragmentation,

[PATCH v3 6/7] block alloc: allocate cache entries from mem_pool

When reading large indexes from disk, a portion of the time is dominated in malloc() calls. This can be mitigated by allocating a large block of memory and manage it ourselves via memory pools. This change moves the cache entry allocation to be on top of memory pools. Design: The index_state

[PATCH v3 4/7] mem-pool: add lifecycle management functions

Add initialization and discard functions to mem-pool type. As part of this, we now also track "large" allocations of memory so that these can also be cleaned up when discarding the memory pool. These changes are in preparation for a future commit that will utilize creating and discarding memory

[PATCH v3 5/7] mem-pool: fill out functionality

Add functions for: - combining two memory pools - determining if a memory address is within the range managed by a memory pool These functions will be used by future commits. Signed-off-by: Jameson Miller --- mem-pool.c | 40

[PATCH v3 7/7] block alloc: add validations around cache_entry lifecyle

Add an option (controlled by an environment variable) perform extra validations on mem_pool allocated cache entries. When set: 1) Invalidate cache_entry memory when discarding cache_entry. 2) When discarding index_state struct, verify that all cache_entries were allocated from expected

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

> The last one (i.e. "even if it is verbose, if fileSize is not > reported, do not write the verbose output") does not look like it is > limited to the unshelve feature, so it might, even though it is a > one-liner, deserve to be a separate preparatory patch if you want. > But I do not feel

Re: bug: --shallow-since misbehaves on old branch heads

I probably can't look into this until the weekend. Just wanted to let you know that I've seen this mail and, being the one who introduced --shallow-since, I will look into it soon (unless someone beats me to it of course). -- Duy

Re: Weird revision walk behaviour

On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote: > On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote: > > > $ git log --oneline master..ba95710a3b -- ci/ > > ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2 > > > > But as far as I can tell, there

Weird revision walk behaviour

There is this topic 'jt/partial-clone-proto-v2' currently cooking in 'next' and pointing to ba95710a3b ({fetch,upload}-pack: support filter in protocol v2, 2018-05-03). This topic is built on top of the merge commit ea44c0a594 (Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2,

Re: Weird revision walk behaviour

On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote: > $ git log --oneline master..ba95710a3b -- ci/ > ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2 > > But as far as I can tell, there are no changes in the 'ci/' directory > on any of the merge's parents: >

"git grep" and "working tree" vs "working directory"

more puzzling terminology, this time in the man page for "git grep". the SYNOPSIS shows, at the very end, the clearly optional "[...]", git grep ... ... snip ... [--] [...] but nowhere in the man page is there an explanation as to the default value used if there is

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

On 23 May 2018 at 17:41, Mazo, Andrey wrote: >> The last one (i.e. "even if it is verbose, if fileSize is not >> reported, do not write the verbose output") does not look like it is >> limited to the unshelve feature, so it might, even though it is a >> one-liner, deserve to