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
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
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 =
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"
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
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
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
"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
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
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
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
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
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
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
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
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
>
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
---
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
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.
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
>
>
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
>> 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
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
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
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
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:
>
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,
> 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
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
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
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
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
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,
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
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 +-
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"
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
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
---
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
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
--
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
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
"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
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
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
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
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
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
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 ---
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.
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
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
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
53 matches
Mail list logo