Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

[PATCH v3 5/5] stash: convert pop to builtin

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

[PATCH v3 4/5] stash: convert branch to builtin

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

[PATCH v3 3/5] stash: convert drop and clear to builtin

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

[PATCH v3 2/5] stash: convert apply to builtin

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

[PATCH v3 0/5] Convert some stash functionality to a builtin

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

[PATCH v3 1/5] stash: improve option parsing test coverage

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

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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

Re: [RFC PATCH 1/1] json-writer: incorrect format specifier

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(>json, key); -

Re: [PATCH v4] json_writer: new routines to create data in JSON format

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

How to `git blame` individual characters?

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

Fwd: New Defects reported by Coverity Scan for git

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:

Re: git submodule update - reset instead of checkout?

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

Re: Will Coverity for FOSS be in scheduled maintenance mode forever?

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,

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

[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

Re: [PATCH v2 01/36] t/helper: add an empty test-tool program

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

Re: [PATCH 04/10] t1405: sort reflog entries in a hash-independent way

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

Re: Including object type and size in object id (Re: Git Merge contributor summit notes)

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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

Re: [PATCH 00/10] Hash-independent tests (part 1)

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

Re: get commit ID from a tree object ID

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 |

Re: [PATCH 04/10] t1405: sort reflog entries in a hash-independent way

"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

Re: get commit ID from a tree object ID

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

Re: [PATCH v2 01/36] t/helper: add an empty test-tool program

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

Re: [GSoC] Convert “git stash” to builtin proposal

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 >

Re: [PATCH v2] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: Should I try to fix rebase interactive preserve-merges bug

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

Re: [PATCH v3] Allow use of TLS 1.3

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

Re: git complains packed-refs is not a directory when used with GIT_DIR and GIT_WORK_TREE envvars.

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

Re: Including object type and size in object id (Re: Git Merge contributor summit notes)

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

Re: [PATCH v3] Allow use of TLS 1.3

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

[PATCH 2/2] mingw/msvc: use the new-style RUNTIME_PREFIX helper

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

[PATCH 1/2] exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows

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

[PATCH 0/2] Add Windows support to the new RUNTIME_PREFIX design

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.

git complains packed-refs is not a directory when used with GIT_DIR and GIT_WORK_TREE envvars.

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

Re: Per-object encryption (Re: Git Merge contributor summit notes)

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

Re: [PATCH v7 0/3] RUNTIME_PREFIX relocatable Git

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

[PATCH] git-stash.txt: remove extra square bracket

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

Re: [PATCH 1/1] repository.h: add comment and clarify repo_set_gitdir

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,

Re: [PATCH 1/1] repository.h: add comment and clarify repo_set_gitdir

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

Including object type and size in object id (Re: Git Merge contributor summit notes)

(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

Re: [PATCH] Remove contrib/examples/*

Æ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

Re: [RFC][PATCH] git-stash: convert git stash list to C builtin

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

Per-object encryption (Re: Git Merge contributor summit notes)

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

Re: [PATCH v4 06/11] pack-objects: move in_pack out of struct object_entry

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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:

Re: [PATCH 00/27] sb/object-store updates

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

Re: [PATCH v2 1/6] stash: Add tests for passing in too many refs

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

Re: [RFC][PATCH] git-stash: convert git stash list to C builtin

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

Re: [PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

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 >

Re: query on git submodule (ignore)

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

Re: Git Merge contributor summit notes

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

Re: [RFC PATCH v5 0/8] rebase-interactive

> 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

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

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

Re: [PATCH 0/2] doc hash-function-transition: minor & major clarifications

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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

Re: [GSoC] Re: Info: git log --oneline improvements

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,

[PATCH 0/2] doc hash-function-transition: minor & major clarifications

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

[PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

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

[PATCH 1/2] doc hash-function-transition: clarify how older gits die on NewHash

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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

Re: [PATCH 00/27] sb/object-store updates

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'

Re: Git Merge contributor summit notes

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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,

Re: Git Merge contributor summit notes

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

Re: [PATCH 00/27] sb/object-store updates

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

Re: [RFC PATCH 1/1] json-writer: incorrect format specifier

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(>json, key); - strbuf_addf(>json,

Re: [RFC PATCH v2 1/1] json-writer: add cast to uintmax_t

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

Re: [PATCH v3 2/3] fast-import: introduce mem_pool type

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

Re: Git Merge contributor summit notes

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 -

Re: [PATCH v2 01/36] t/helper: add an empty test-tool program

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

[PATCH v3 1/3] fast-import: rename mem_pool type to mp_block

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

[PATCH v3 2/3] fast-import: introduce mem_pool type

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

Re: [PATCH v7 00/13] nd/pack-objects-pack-struct updates

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

[PATCH v3 0/3] Extract memory pool logic into reusable component

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

Re: [RFC PATCH 1/1] json-writer: incorrect format specifier

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(>json, key); >>> - strbuf_addf(>json, ":%"PRIuMAX, value); >>> +

[PATCH v3 3/3] Move reusable parts of memory pool into its own file

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

Re: [RFC PATCH v5 0/8] rebase-interactive

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(>json,

[PATCH/RFC 4/5] git.c: implement --list-cmds=porcelain

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

[PATCH/RFC 5/5] help: add "-a --verbose" to list all commands with synopsis

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

[PATCH/RFC 3/5] generate-cmdlist.sh: keep all information in common-cmds.h

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.

[PATCH/RFC 1/5] git.c: convert --list-builtins to --list-cmds=builtins

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

[PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

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

[PATCH/RFC 2/5] git.c: implement --list-cmds=all and use it in git-completion.bash

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

Re: [PATCH v2] branch: implement shortcut to delete last branch

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

Re: [ANNOUNCE] Git v2.17.0-rc1

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.

Re: [RFC PATCH v5 0/8] rebase-interactive

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(>json, ":%"PRIuMAX, value); >

Re: [PATCH v2 01/36] t/helper: add an empty test-tool program

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

Re: [PATCH v7 00/13] nd/pack-objects-pack-struct updates

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; > + struct pack_window *w_curs; > + unsigned char *buf; > +

Re: [PATCH v7 0/3] RUNTIME_PREFIX relocatable Git

On Mon, Mar 26, 2018 at 10:08 AM Ævar Arnfjörð Bjarmason wrote: > > Oh sorry, I must have missed that. I have a personal preference for adding > > brackets for clarity; it leaked into this patch set. I did implement most > > of the suggestion, which was to use the escaped Q/E

Re: [RFC 0/1] Tolerate broken headers in `packed-refs` files

On Mon, Mar 26, 2018 at 2:08 PM, Derrick Stolee wrote: > Since most heavily-used tools that didn't spawn Git processes use > LibGit2 to interact with Git repos, I added Ed Thomson to CC to see > if libgit2 could ever write these bad header comments. We added the `sorted`

Re: [RFC 0/1] Tolerate broken headers in `packed-refs` files

On Mon, Mar 26, 2018 at 09:08:04AM -0400, Derrick Stolee wrote: > Since most heavily-used tools that didn't spawn Git processes use LibGit2 to > interact with Git repos, I added Ed Thomson to CC to see if libgit2 could > ever write these bad header comments. Ed can probably answer more

[PATCH v4] json_writer: new routines to create data in JSON format

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 can be used to generate structured data

[PATCH v4] routines to generate JSON data

From: Jeff Hostetler This is version 4 of my JSON data format routines. This version adds a "pretty" formatted output. I consider this to be mainly for debugging, but worth keeping available in release builds. I simplified the stack-level tracing as suggested by René

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Buga, On Fri, 16 Mar 2018, Igor Djordjevic wrote: > [...] > > Yes, having more steps would mean more power/options to the user, but > more complexity to explain to and guide him through as well, not really > sure where the line should be drawn - for the first time, at least. If you want to

  1   2   >