Hello dear how are you?
Nice to meet you,my name is Miss Nadege Yann, can we become friends? hope to
hear from you so that we can know each other very well, love matters mostly in
life,i will also send you my pictures and tell you more about myself, my email
address is( missnade...@gmail.com )
On Mon, Mar 26, 2018 at 10:27:09PM +0100, Rafael Ascensao wrote:
> One of the tools that manages PKGBUILDS for Arch Linux stores PKGBUILD
> git repos inside a cache directory for reuse.
>
> One of the repos is triggering some unexpected behaviour that can be
> reproduced in the CLI with:
>
> $
--
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
--
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
On Sun, Mar 25, 2018 at 4:38 PM, Paul-Sebastian Ungureanu
wrote:
> On 25.03.2018 12:46, Christian Couder wrote:
>>
>> On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu
>> wrote:
>>>
>>> On 23.03.2018 19:11, Christian Couder wrote:
>>>
> * Ensure that no regression occurred: considerin
Hi,
On Tue, Mar 27, 2018 at 2:18 AM, Jan Keromnes wrote:
> Dear Git developers,
>
> I'd like to understand what would be required to run `git blame` on
> individual characters instead of full lines. Could you please point me
> in the right direction?
You might want to take a look at cregit
(http
Hi Johannes,
Johannes Schindelin writes:
> Hi Buga,
>
> On Tue, 13 Mar 2018, Igor Djordjevic wrote:
>
>> On 12/03/2018 11:46, Johannes Schindelin wrote:
>> >
>> > > Sometimes one just needs to read the manual, and I don`t really
>> > > think this is a ton complicated, but just something we didn
Add stash pop to the helper and delete the pop_stash, drop_stash,
assert_stash_ref and pop_stash functions from the shell script
now that they are no longer needed.
Signed-off-by: Joel Teichroeb
---
builtin/stash--helper.c | 41
git-stash.sh|
Add stash branch to the helper and delete the apply_to_branch
function from the shell script.
Signed-off-by: Joel Teichroeb
---
builtin/stash--helper.c | 47 +++
git-stash.sh| 17 ++---
2 files changed, 49 insertions(+), 15 dele
Add the drop and clear commands to the builtin helper. These two
are each simple, but are being added together as they are quite
related.
We have to unfortunately keep the drop and clear functions in the
shell script as functions are called with parameters internally
that are not valid when the co
Add a bulitin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
let conversion get started without the other command being
finished.
The helper is being implemented as a drop in replacement for
stash so that when it is complete it can s
I've been working on converting all of git stash to be a
builtin, however it's hard to get it all working at once with
limited time, so I've moved around half of it to a new
stash--helper builtin and called these functions from the shell
script. Once this is stabalized, it should be easier to conve
In preparation for converting the stash command incrementally to
a builtin command, this patch improves test coverage of the option
parsing. Both for having too many paramerters, or too few.
Signed-off-by: Joel Teichroeb
---
t/t3903-stash.sh | 16
1 file changed, 16 insertions(+
Hi Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> [...]
>>
>> Yet another consequence is that my approach will likely result in better
>> code reuse.
>
> This is a purely academic speculation. At least until somebody implements
> Phillip's
Dear Johannes,
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>>
>> > [...]
>> >
>> > Where "easy" meant that I had to spend 1h still to figure out why
>> > using the unrebased merge parents as merge bases.
>>
>> That's
Johannes Schindelin writes:
> Hi Sergey,
>
> On Mon, 12 Mar 2018, Sergey Organov wrote:
>
>> Johannes Schindelin writes:
>> >
>> > On Wed, 7 Mar 2018, Sergey Organov wrote:
>> >
>> >> Johannes Schindelin writes:
>> >>
>> >> > How can your approach -- which relies *very much* on having the
>> >
Hi Johannes,
Johannes Schindelin writes:
> Hi Buga,
>
> On Tue, 13 Mar 2018, Igor Djordjevic wrote:
>
>> On 12/03/2018 13:56, Sergey Organov wrote:
>> >
>> > > > I agree with both of you that `pick ` is inflexible
>> > > > (not to say just plain wrong), but I never thought about it like
>> > > >
Jeff Hostetler writes:
> I did the uint64_t for the unsigned ns times.
>
> I did the other one for the usual signed ints.
>
> I could convert them both to a single signed 64 bit typed function
> if we only want to have one function.
I still think having sized version is a horrible idea, and reco
On 26/03/18 18:04, Junio C Hamano wrote:
> Ramsay Jones writes:
>
@@ -120,7 +120,7 @@ void jw_object_uint64(struct json_writer *jw, const
char *key, uint64_t value)
maybe_add_comma(jw);
append_quoted_string(&jw->json, key);
- strbuf_addf(&jw->json, ":%"PR
On 26/03/18 15:31, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Add a series of jw_ routines and "struct json_writer" structure to compose
> JSON data. The resulting string data can then be output by commands wanting
> to support a JSON output format.
>
> The json-writer routines
Dear Git developers,
I'd like to understand what would be required to run `git blame` on
individual characters instead of full lines. Could you please point me
in the right direction?
Someone asked a similar question about "Word-by-word blame/annotate"
on StackOverflow a few years ago, and one of
coverity scan failed for the last couple month (since Nov 20th)
without me noticing, I plan on running it again nightly for the
Git project.
Anyway, here are issues that piled up (in origin/pu) since then.
Stefan
-- Forwarded message --
From:
Date: Mon, Mar 26, 2018 at 4:24 PM
On Fri, Mar 9, 2018 at 7:07 AM Andreas Krey wrote:
> Hi everyone,
> I've been reading up on the current state of git submodules
> (our customer's customers want to use them, causing a slight
> groan from our customer).
> The usability thing I wonder about - with git submodule update,
> is it ne
On Tue, Mar 13, 2018 at 7:00 AM Johannes Schindelin <
johannes.schinde...@gmx.de> wrote:
> Hi Coverity (now Synopsys) team,
> I probably managed to miss important mails such as announcing that the
> Coverity service for FOSS projects would be unavailable for some time.
> Since February 20th, thi
[snipped the cc list as well]
On Tue, Mar 6, 2018 at 12:06 PM Eddy Petrișor
wrote:
> Signed-off-by: Eddy Petrișor
> ---
Did this go anywhere?
(I just came back from a longer vacation, sorry for the delay on my site)
> There are projects such as llvm/clang which use several repositories, and
t
On Tue, Mar 27, 2018 at 12:14 AM, Johannes Schindelin
wrote:
> However, it seems that something is off, as
> ba5bec9589e9eefe2446044657963e25b7c8d88e is reported as fine on Windows:
> https://travis-ci.org/git/git/jobs/358260023 (while there is clearly a red
> X next to that commit in
> https://gi
On Mon, Mar 26, 2018 at 03:18:20PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > The test enumerates reflog entries in an arbitrary order and then sorts
> > them. For SHA-1, this produces results that happen to sort in
> > alphabetical order, but for other hash algorithms they
Jonathan Nieder writes:
> This implies a limit on the object size (e.g. 5 bytes in your
> example). What happens when someone wants to encode an object larger
> than that limit?
>
> This also decreases the number of bits available for the hash, but
> that shouldn't be a big issue.
I actually th
Hi all,
On Mon, 26 Mar 2018, Wink Saville wrote:
> > I was just going by what the reported compiler error message was.
> > It said that "unsigned long" didn't match the uint64_t variable.
> > And that made me nervous.
> >
> > If all of the platforms we build on define uintmax_t >= 64 bits,
> > th
On Sun, Mar 25, 2018 at 10:10:21PM -0400, Eric Sunshine wrote:
> What's the plan for oddball cases such as 66ae9a57b8 (t3404: rebase
> -i: demonstrate short SHA-1 collision, 2013-08-23) which depend
> implicitly upon SHA-1 without actually hardcoding any hashes? The test
> added by 66ae9a57b8, for
Hi,
Stefan Beller wrote:
> On Sat, Mar 17, 2018 at 10:57 AM Junio C Hamano wrote:
>> Jeff King writes:
>>> If you want to dig further, you can use the diff machinery to show which
>>> commit introduced a particular tree, like:
>>>
>>> git rev-list --all |
>>> git diff-tree --stdin --pretty=
"brian m. carlson" writes:
> The test enumerates reflog entries in an arbitrary order and then sorts
> them. For SHA-1, this produces results that happen to sort in
> alphabetical order, but for other hash algorithms they sort differently.
> Ensure we sort the reflog entries in a hash-independen
On Sat, Mar 17, 2018 at 10:57 AM Junio C Hamano wrote:
> Jeff King writes:
> > If you want to dig further, you can use the diff machinery to show which
> > commit introduced a particular tree, like:
> >
> > git rev-list --all |
> > git diff-tree --stdin --pretty=raw --raw -t -r |
> > less
Hi Duy,
On Mon, 26 Mar 2018, Duy Nguyen wrote:
> On Mon, Mar 26, 2018 at 5:27 PM, Johannes Schindelin
> wrote:
> >
> > On Sat, 24 Mar 2018, Nguyễn Thái Ngọc Duy wrote:
> >
> >> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
> >> new file mode 100644
> >> index 00..c730f718ca
>
Hi Paul,
On Sun, 25 Mar 2018, Paul-Sebastian Ungureanu wrote:
> One thing I did not mention in the previous reply was that I also added
> a new paragraph to "Benefits to community" about 'git stash' being slow
> on Windows for a lot of users. I consider this alone to be a very good
> justificatio
Nguyễn Thái Ngọc Duy writes:
> The set of extra warnings we enable when DEVELOPER has to be
> conservative because we can't assume any compiler version the
> developer may use. Detect the compiler version so we know when it's
> safe to enable -Wextra and maybe more.
This is a good idea in gener
Hi Jake & Wink,
On Sun, 25 Mar 2018, Jacob Keller wrote:
> On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville wrote:
> > There is a "TODO known breakage" in t3404-rebase-interactve.sh:
> >
> >not ok 24 - exchange two commits with -p # TODO known breakage
> >
> > I'm contemplating trying to fix i
On Mon, 26 Mar 2018, Johannes Schindelin wrote:
Can we *please* also add that OpenSSL 1.1.* is required (or that cURL is
built with NSS or BoringSSL as the TLS backend)?
We might consider adding a way to extract that info from curl to make that
work really good for you. There are now six TLS
On Mon, Mar 26 2018, Rafael Ascensao wrote:
> One of the tools that manages PKGBUILDS for Arch Linux stores PKGBUILD
> git repos inside a cache directory for reuse.
>
> One of the repos is triggering some unexpected behaviour that can be
> reproduced in the CLI with:
>
> $ GIT_DIR=spotify/.git
On 3/26/2018 5:00 PM, Jonathan Nieder wrote:
Jeff Hostetler wrote:
[long quote snipped]
While we are converting to a new hash function, it would be nice
if we could add a couple of fields to the end of the OID: the object
type and the raw uncompressed object size.
If would be nice if we cou
Hi Logan,
On Mon, 26 Mar 2018, Loganaden Velvindron wrote:
> Add a tlsv1.3 option to http.sslVersion in addition to the existing
> tlsv1.[012] options. libcurl has supported this since 7.52.0.
>
> Signed-off-by: Loganaden Velvindron
Can we *please* also add that OpenSSL 1.1.* is required (or t
This change also allows us to stop overriding argv[0] with the absolute
path of the executable, allowing us to preserve e.g. the case of the
executable's file name.
This fixes https://github.com/git-for-windows/git/issues/1496 partially.
Signed-off-by: Johannes Schindelin
---
compat/mingw.c |
The RUNTIME_PREFIX feature comes from Git for Windows, but it was
enhanced to allow support for other platforms. While changing the
original idea, the concept was also improved by not forcing argv[0] to
be adjusted.
Let's allow the same for Windows by implementing a helper just as for
the other pl
Even if the RUNTIME_PREFIX feature originates from Git for Windows, the
current patch series is different enough in its design that it leaves the
Windows-specific RUNTIME_PREFIX handling in place: On Windows, we still
have to override argv[0] with the absolute path of the current `git`
executable.
One of the tools that manages PKGBUILDS for Arch Linux stores PKGBUILD
git repos inside a cache directory for reuse.
One of the repos is triggering some unexpected behaviour that can be
reproduced in the CLI with:
$ GIT_DIR=spotify/.git GIT_WORK_TREE=spotify git reset HEAD
fatal: couldn't rea
On Mon, Mar 26 2018, Jonathan Nieder wrote:
> Hi Ævar,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> It occurred to me recently that once we have such a layer it could be
>> (ab)used with some relatively minor changes to do any arbitrary
>> local-to-remote object content translation, unless I've missed
Hi,
On Mon, 26 Mar 2018, Daniel Jacques wrote:
> On Mon, Mar 26, 2018 at 2:01 AM Junio C Hamano wrote:
>
> > I wonder if the relocatable Git would allow a simpler arrangement to
> > test without installing.
>
> > I am asking merely out of curiosity, not suggesting to make a trial
> > install s
In 1ada5020b3 ("stash: use stash_push for no verb form", 2017-02-28),
when the pathspec argument was introduced in 'git stash', that was also
documented. However I forgot to remove an extra square bracket after
the '--message' argument, even though the square bracket should have
been after the pat
On Mon, Mar 26, 2018 at 2:04 PM Stefan Beller wrote:
> On Fri, Mar 23, 2018 at 8:55 AM Nguyễn Thái Ngọc Duy
wrote:
> >
> > The argument name "optional" may mislead the reader to think this
> > option could be NULL. But it can't be. While at there, document a bit
> > more about struct set_gitdi
On Fri, Mar 23, 2018 at 8:55 AM Nguyễn Thái Ngọc Duy
wrote:
> The argument name "optional" may mislead the reader to think this
> option could be NULL. But it can't be. While at there, document a bit
> more about struct set_gitdir_args.
> Signed-off-by: Nguyễn Thái Ngọc Duy
Reviewed-by: Stefan
(administrivia: please omit parts of the text you are replying to that
are not relevant to the reply. This makes it easier to see what you're
replying to, especially in mail readers that don't hide quoted text by
the default)
Hi Jeff,
Jeff Hostetler wrote:
[long quote snipped]
> While we are
Ævar Arnfjörð Bjarmason writes:
> + * Doing `git log` on paths matching '*--helper.c' will show
> + incremental effort in the direction of moving existing shell
> + scripts to C.
It may be benefitial to remind readers of "--full-diff", e.g.
$ git log --full-diff --stat -p -- "${foo}--he
On 03/26, Johannes Schindelin wrote:
> Hi Eric,
>
> On Sun, 25 Mar 2018, Eric Sunshine wrote:
>
> > On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu
> > wrote:
> > > Currently, because git stash is not fully converted to C, I
> > > introduced a new helper that will hold the converted co
Hi Ævar,
Ævar Arnfjörð Bjarmason wrote:
> It occurred to me recently that once we have such a layer it could be
> (ab)used with some relatively minor changes to do any arbitrary
> local-to-remote object content translation, unless I've missed something
> (but I just re-read hash-function-transiti
Hi,
sorry for the late review, as I am pointed here indirectly via
https://public-inbox.org/git/xmqqy3iebpsw@gitster-ct.c.googlers.com/
On Fri, Mar 16, 2018 at 11:33 AM Nguyễn Thái Ngọc Duy
wrote:
> +LIMITATIONS
> +---
> +
> +This command could only handle 16384 existing pack files
Wink Saville writes:
> Should we add a "_Static_assert" that sizeof(uintmax_t) >= sizeof(uint64_t) ?
If that expression compiles, then both types are understood by the
platform. Because
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
tells us:
Greatest-width intege
Junio C Hamano writes:
> Stefan Beller writes:
>
>> Thanks for driving this when I was away!
>>
>> With the fixup patch, both series are
>> Reviewed-by: Stefan Beller
>
> I think everybody involved agrees that these two you cited above are
> already in good shape. Let's have them in 'next' for
Hi Joel,
On Sun, 25 Mar 2018, Joel Teichroeb wrote:
> Signed-off-by: Joel Teichroeb
I could imagine that the commit message would benefit from this body:
In preparation for converting the stash command incrementally to
a builtin command, this patch improves test coverage of the
Hi Eric,
On Sun, 25 Mar 2018, Eric Sunshine wrote:
> On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu
> wrote:
> > Currently, because git stash is not fully converted to C, I
> > introduced a new helper that will hold the converted commands.
> > ---
> > diff --git a/builtin/stash--helpe
On Mon, Mar 26, 2018 at 2:27 PM, Ævar Arnfjörð Bjarmason
wrote:
> Attempt to clarify what the SHAttered attack means in practice for
> Git. The previous version of the text made no mention whatsoever of
> Git already having a mitigation for this specific attack, which the
> SHAttered researchers c
On Sun, Mar 25, 2018 at 9:46 AM Junio C Hamano wrote:
> prashant Nidgunde writes:
> [cc: stefan, for his interest in improving 'git submodules']
> > Hello,
> >
> > I am new to this community ,so please ignore if I am asking anything
silly.
> >
> > Case :
> > Today when I built my submodule , a
On 3/26/2018 1:56 PM, Stefan Beller wrote:
On Mon, Mar 26, 2018 at 10:33 AM Jeff Hostetler
wrote:
On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
On Sat, Mar 10 2018, Alex Vandiver wrote:
New hash (Stefan, etc)
--
- discussed on the mailing list
- actual
> I was just going by what the reported compiler error message was.
> It said that "unsigned long" didn't match the uint64_t variable.
> And that made me nervous.
>
> If all of the platforms we build on define uintmax_t >= 64 bits,
> then it doesn't matter.
>
> If we do have a platform where uintma
On Mon, Mar 26, 2018 at 12:44 AM, Eric Sunshine wrote:
> On Mon, Mar 26, 2018 at 3:25 AM, Jeff King wrote:
>> OK, so here's some patches. We could do the first three now, wait a
>> while before the fourth, and then wait a while (or never) on the fifth.
>>
>> [1/5]: t3200: unset core.logallrefup
On Mon, Mar 26, 2018 at 11:27 AM Ævar Arnfjörð Bjarmason
wrote:
> Having read through the hash-function-transition.txt again, a couple
> of things jumped out at me:
> Ævar Arnfjörð Bjarmason (2):
>doc hash-function-transition: clarify how older gits die on NewHash
> We weren't accurately de
On 3/26/2018 2:00 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
I am concerned that the above compiler error message says that uintmax_t
is defined as an "unsigned long" (which is defined as *at least* 32 bits,
but not necessarily 64. But a uint64_t is defined as a "unsigned long long"
a
On Sat, Mar 24, 2018 at 4:15 AM Christian Couder
wrote:
> Hi,
> On Sat, Mar 24, 2018 at 9:41 AM, Pratik Karki
wrote:
> >
> > Hi Christian and Johannes,
> >
> > Though I sent a mail earlier, saying I would like to submit another
> > proposal, I am now skeptical on re-writing another proposal as
Having read through the hash-function-transition.txt again, a couple
of things jumped out at me:
Ævar Arnfjörð Bjarmason (2):
doc hash-function-transition: clarify how older gits die on NewHash
We weren't accurately describing how "git status" would die on NewHash
repos on new versions.
doc
Attempt to clarify what the SHAttered attack means in practice for
Git. The previous version of the text made no mention whatsoever of
Git already having a mitigation for this specific attack, which the
SHAttered researchers claim will detect cryptanalytic collision
attacks.
I may have gotten some
Change the "Repository format extension" to accurately describe what
happens with different versions of Git when they encounter NewHash
repositories, instead of only saying what happens with versions v2.7.0
and later.
See ab9cb76f66 ("Repository format version check.", 2005-11-25) and
00a09d57eb (
On 3/26/2018 1:57 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
I defined that routine to take a uint64_t because I wanted to
pass a nanosecond value received from getnanotime() and that's
what it returns.
Hmph, but the target format does not have different representation
of inttypes in
Stefan Beller writes:
> Thanks for driving this when I was away!
>
> With the fixup patch, both series are
> Reviewed-by: Stefan Beller
I think everybody involved agrees that these two you cited above are
already in good shape. Let's have them in 'next' for the remainder
of this cycle and go i
On 03/26, Jeff Hostetler wrote:
>
>
> On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Sat, Mar 10 2018, Alex Vandiver wrote:
> >
> > > New hash (Stefan, etc)
> > > --
> > > - discussed on the mailing list
> > > - actual plan checked in to
> > > Documenta
Jeff Hostetler writes:
> I am concerned that the above compiler error message says that uintmax_t
> is defined as an "unsigned long" (which is defined as *at least* 32 bits,
> but not necessarily 64. But a uint64_t is defined as a "unsigned long long"
> and guaranteed as a 64 bit value.
On a pl
Jeff Hostetler writes:
> I defined that routine to take a uint64_t because I wanted to
> pass a nanosecond value received from getnanotime() and that's
> what it returns.
Hmph, but the target format does not have different representation
of inttypes in different sizes, no?
I personally doubt
On Mon, Mar 26, 2018 at 10:33 AM Jeff Hostetler
wrote:
> On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Sat, Mar 10 2018, Alex Vandiver wrote:
> >
> >> New hash (Stefan, etc)
> >> --
> >> - discussed on the mailing list
> >> - actual plan checked in to
D
On Fri, Mar 23, 2018 at 10:31 PM Duy Nguyen wrote:
> I got too excited when searching and replacing. Here's the fixup
> patch.
Thanks for picking up the series that I left unattended over the last weeks.
I have reviewed nd/remove-ignore-env-field as well as sb/object-store
as currently queued an
On 3/26/2018 1:04 PM, Junio C Hamano wrote:
Ramsay Jones writes:
@@ -120,7 +120,7 @@ void jw_object_uint64(struct json_writer *jw, const char
*key, uint64_t value)
maybe_add_comma(jw);
append_quoted_string(&jw->json, key);
- strbuf_addf(&jw->json, ":%"PRIuMAX, value);
+
On 3/24/2018 2:38 PM, Wink Saville wrote:
Correct a compile error on Mac OSX by adding a cast to uintmax_t
in calls to strbuf_addf.
Helped-by: Ramsay Jones
Tested-by: travis-ci
Signed-off-by: Wink Saville
---
json-writer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
On Mon, Mar 26, 2018 at 1:03 PM, Jameson Miller wrote:
> Introduce the mem_pool type which encapsulates all the information
> necessary to manage a pool of memory.This change moves the existing
s/memory\.This/memory. This/
> variables in fast-import used to support the global memory pool to use
On 3/25/2018 6:58 PM, Ævar Arnfjörð Bjarmason wrote:
On Sat, Mar 10 2018, Alex Vandiver wrote:
New hash (Stefan, etc)
--
- discussed on the mailing list
- actual plan checked in to
Documentation/technical/hash-function-transition.txt
- lots of work renaming
- any
On Mon, Mar 26, 2018 at 5:27 PM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On Sat, 24 Mar 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
>> new file mode 100644
>> index 00..c730f718ca
>> --- /dev/null
>> +++ b/t/helper/test-tool.c
>> @@ -0,0
This is part of a patch series to extract the memory pool logic in
fast-import into a more generalized version. The existing mem_pool type
maps more closely to a "block of memory" (mp_block) in the more
generalized memory pool. This commit renames the mem_pool to mp_block to
reduce churn in future
Introduce the mem_pool type which encapsulates all the information
necessary to manage a pool of memory.This change moves the existing
variables in fast-import used to support the global memory pool to use
this structure.
These changes allow for the multiple instances of a memory pool to
exist and
On Mon, Mar 26, 2018 at 5:13 PM, Jeff King wrote:
> On Sat, Mar 24, 2018 at 07:33:40AM +0100, Nguyễn Thái Ngọc Duy wrote:
>
>> +unsigned long oe_get_size_slow(struct packing_data *pack,
>> +const struct object_entry *e)
>> +{
>> + struct packed_git *p;
>> + stru
Changes from v2:
- Code Review Reactions
- Lifetime management functions for mem_pool will be included in
future patch series
This patch series extracts the memory pool implementation, currently
used by fast-import, into a generalized component. This memory pool
can then be generally u
Ramsay Jones writes:
>>> @@ -120,7 +120,7 @@ void jw_object_uint64(struct json_writer *jw, const
>>> char *key, uint64_t value)
>>> maybe_add_comma(jw);
>>>
>>> append_quoted_string(&jw->json, key);
>>> - strbuf_addf(&jw->json, ":%"PRIuMAX, value);
>>> + strbuf_addf(&jw->json, ":%"
This moves the reusable parts of the memory pool logic used by
fast-import.c into its own file for use by other components.
Signed-off-by: Jameson Miller
---
Makefile | 1 +
fast-import.c | 70 +--
mem-pool.c| 55 +
On 3/26/2018 11:56 AM, Junio C Hamano wrote:
Wink Saville writes:
json-writer.c:123:38: error: format specifies type 'uintmax_t' (aka
'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
long long') [-Werror,-Wformat]
strbuf_addf(&jw->json, ":%"PRIuMAX, value);
This is useful for git-completion.bash because it needs this set of
commands. Right now we have to maintain a separate command category in
there.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 94 ++
git.c
common-cmds.h is used to extract the list of common commands (by
group) and a one-line summary of each command. Some information is
dropped, for example command category or summary of other commands.
Update generate-cmdlist.sh to keep all the information. The extra info
will be used shortly.
Signe
Even if this is a hidden option, let's make it a bit more generic
since we're introducing more listing types.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
git.c | 7 +--
t/t0012-help.sh | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git.c b/git.c
index ceaa58ef40
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-help.txt | 4 ++-
builtin/help.c | 6
help.c | 61 ++
help.h | 1 +
4 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/Documentatio
This is pretty rough but I'd like to see how people feel about this
first.
I notice we have two places for command classification. One in
command-list.txt, one in __git_list_porcelain_commands() in
git-completion.bash. People who are following nd/parseopt-completion
probably know that I'm try to r
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 2 +-
git.c | 2 ++
help.c | 15 +++
help.h | 1 +
4 files changed, 19 insertions(+), 1 deletion(-)
dif
g...@matthieu-moy.fr writes:
>> That said, I'd still be OK with it.
>
> I don't have objection either.
FWIW, I do not even buy the "destructive commands should force
spelling things out even more" argument in the first place.
$ git checkout somelongtopicname
$ work work work
$ git ch
Hi Bryan,
On Fri, 23 Mar 2018, Bryan Turner wrote:
> On Fri, Mar 23, 2018 at 10:47 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 21 Mar 2018, Junio C Hamano wrote:
> >
> >> A release candidate Git v2.17.0-rc1 is now available for testing
> >> at the usual places. It is comprised of 493 non-m
Wink Saville writes:
> json-writer.c:123:38: error: format specifies type 'uintmax_t' (aka
> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
> long long') [-Werror,-Wformat]
>
> strbuf_addf(&jw->json, ":%"PRIuMAX, value);
> ~~
Hi Duy,
On Sat, 24 Mar 2018, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
> new file mode 100644
> index 00..c730f718ca
> --- /dev/null
> +++ b/t/helper/test-tool.c
> @@ -0,0 +1,27 @@
> +#include "git-compat-util.h"
> +#include "test-tool.h"
> +
>
1 - 100 of 152 matches
Mail list logo