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

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

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

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

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: [PATCH v2 1/4] builtin/config: introduce `--default`

On Fri, Mar 23, 2018 at 08:55:53PM -0400, Taylor Blau wrote: > This commit (and those following it in this series) aim to eventually > replace `--get-color` with a consistent alternative. By introducing > `--default`, we allow the `--get-color` action to be promoted to a > `--color` type

Re: [PATCH v2 3/6] stash: convert apply to builtin

On Mon, Mar 26, 2018 at 3:14 AM, Joel Teichroeb wrote: > Signed-off-by: Joel Teichroeb The commit message in this patch and the following ones could be a bit more verbose. It could at least tell that the end goal is to convert git-stash.sh to a C builtin.

Re: [PATCH v2 0/4] Teach `--default` to `git-config(1)`

On Fri, Mar 23, 2018 at 08:55:52PM -0400, Taylor Blau wrote: > Attached is 'v2' of my patch series to add a `--default` option to `git > config`. Thanks, this is looking much better. I did come up with a few suggestions/fixes. Some minor which would make v3 easy, and some that would require

Cześć słodka

Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym znowu czuję się kochana ... Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka .. Proszę wybaczyć moje

Cześć słodka

Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym znowu czuję się kochana ... Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka .. Proszę wybaczyć moje

Re: [PATCH v2 4/4] builtin/config: introduce `--color` type specifier

On Fri, Mar 23, 2018 at 08:55:56PM -0400, Taylor Blau wrote: > As of this commit, the canonical way to retreive an ANSI-compatible > color escape sequence from a configuration file is with the > `--get-color` action. s/retreive/retrieve/ > This is to allow Git to "fall back" on a default value

[PATCH 1/5] t3200: unset core.logallrefupdates when testing reflog creation

This test checks that the "-l" option creates a reflog. But in fact we'd create one even without it, since the default in a non-bare repository is to do so. Let's unset the config so we can be sure our "-l" option is kicking in. Note that we can't do this with test_config, since that would leave

[PATCH 2/5] t: switch "branch -l" to "branch --create-reflog"

In preparation for deprecating "-l", let's make sure we're using the recommended option ourselves. This patch just mechanically converts "branch -l" to "branch --create-reflog". Note that with the exception of the actual "--create-reflog" test, we could actually remove "-l" entirely from most of

[PATCH v2 1/2] perf/aggregate: add display_dir()

This new helper function will be reused in a subsequent commit. Signed-off-by: Christian Couder --- t/perf/aggregate.perl | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl index

git shortlog --author=Me

If I have a .mailmap file containing Me brendanator And I run git log --author=Me I see all my commits However if I run git shortlog --author=Me my commits are not shown

FW: Merging in Git with Branches

Hi Git team, I have a query. Scenario: Currently there are two main branches that we are utilizing A(master) and B(branch of A). Branch is utilised for individual stories(as per delivery). When branch is utilised since the team size is huge the number of changes/ branches created for

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

On Fri, Mar 23, 2018 at 10:40:34PM +, Aaron Greenberg wrote: > I updated the commit message to include my first email's cover letter > and cleaned up the test. Thanks. This one looks good to me. > I can appreciate Matthieu's points on the use of "-" in destructive > commands. As of this

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

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.logallrefupdates when testing reflog creation > [2/5]:

[PATCH 4/5] branch: drop deprecated "-l" option

We marked the "-l" option as deprecated back in . Now that sufficient time has passed, let's follow through and get rid of it. Signed-off-by: Jeff King --- I'll need some help from the maintainer on the commit message. :) builtin/branch.c | 15 --- 1 file changed, 15

[PATCH 3/5] branch: deprecate "-l" option

The "-l" option is short for "--create-reflog". This has caused much confusion over the years. Most people expect it to work as "--list", because that would match the other "mode" options like -d/--delete and -m/--move, as well as the similar -l/--list option of git-tag. Adding to the confusion,

[PATCH 5/5] branch: make "-l" a synonym for "--list"

The other "mode" options of git-branch have short-option aliases that are easy to type (e.g., "-d" and "-m"). Let's give "--list" the same treatment. This also makes it consistent with the similar "git tag -l" option. We didn't do this originally because "--create-reflog" was squatting on the

Re: [PATCH v2 2/4] Documentation: list all type specifiers in config prose

On Fri, Mar 23, 2018 at 08:55:54PM -0400, Taylor Blau wrote: > The documentation for the `git-config(1)` builtin has not been recently > updated to include new types, such as `--bool-or-int`, and > `--expiry-date`. To ensure completeness when adding a new type > specifier, let's update the

[PATCH v3] Allow use of TLS 1.3

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 --- Documentation/config.txt | 1 + http.c | 3 +++ 2 files changed, 4 insertions(+) diff

Re: [PATCH] Remove contrib/examples/*

On Sun, Mar 25, 2018 at 08:46:53PM +, Ævar Arnfjörð Bjarmason wrote: > There were some side discussions at Git Merge this year about how we > should just update the README to tell users they can dig these up from > the history if the need them, do that. > > Looking at the "git log" for this

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

Dan Jacques writes: > This patch set expands support for the RUNTIME_PREFIX configuration flag, > currently only used on Windows builds, to include Linux, Darwin, and > FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its > ancillary paths relative to the

[PATCH v2 2/2] perf/aggregate: add --sort-by=regression option

One of the most interesting thing one can be interested in when looking at performance test results is possible performance regressions. This new option makes it easy to spot such possible regressions. This new option is named '--sort-by=regression' to make it possible and easy to add other ways

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

On Sun, Mar 25, 2018 at 12:15:42AM -0700, Jacob Keller wrote: > > 3. Drop "-l" (probably with a deprecation period); it seems unlikely > > to me that anybody uses it for branch creation, and this would at > > least reduce the confusion (then it would just be "so why don't we > >

[PATCH v2 0/2] perf/aggregate: sort results by regression

This small patch series makes it easy to spot big performance regressions, so that they can later be investigated. For example: $ ./aggregate.perl --sort-by=regression --subsection "without libpcre" v2.14.3 v2.15.1 v2.16.2 p4220-log-grep-engines.sh +5.0% p4220-log-grep-engines.2

[PATCH] test_must_be_empty: simplify file existence check

Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not just empty, 2018-02-27) basically duplicated the 'test_path_is_file' helper function in 'test_must_be_empty'. Just call 'test_path_is_file' to avoid this code duplication. Signed-off-by: SZEDER Gábor ---

[PATCH v2] test_must_be_empty: simplify file existence check

Commit 11395a3b4b (test_must_be_empty: make sure the file exists, not just empty, 2018-02-27) basically duplicated the 'test_path_is_file' helper function in 'test_must_be_empty'. Just call 'test_path_is_file' to avoid this code duplication. Signed-off-by: SZEDER Gábor ---

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

Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote: > On 12/03/2018 11:20, Johannes Schindelin wrote: > > > > > > [...] and cannot introduce ambiguities when rebasing the > > > > changes introduced by M (i.e. the "amendmendts" we talked about). > > > > > > Hmm, not following here, which

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

Hi Junio, On Tue, 13 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > If so, what tooling do you have to identify quickly what to > > cherry-pick, given merge conflicts? > > It exactly is the issue I've been trying to find ideal solution for >

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

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 > > > > that. > > > > > > > > If we are to extract further

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

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`t really > > > have before (real merge rebasing), so

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

On 3/26/2018 8:42 AM, Michael Haggerty wrote: [...] But there might be some tools out in the wild that have been writing broken headers. In that case, users who upgrade Git might suddenly find that they can't read repositories that they could read before. In fact, a tool that we wrote and use

+Hey,i am Lindsey ,How's everything with you,I have interest on you after going through your profile I really want to have a good friendship with you.Beside i have something very vital to tell you

Re: FW: Merging in Git with Branches

On Mon, Mar 26, 2018 at 10:12:04AM +, shirlin.jos...@bt.com wrote: [...] > Currently there are two main branches that we are utilizing A(master) > and B(branch of A). Branch is utilised for individual stories(as per > delivery). [...] Cross-posted to [1] as well. 1.

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

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 method. Oh wait, I already started to implement it, and

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

Hi Sergey, On Mon, 12 Mar 2018, Sergey Organov wrote: > Johannes Schindelin writes: > > Hi Sergey, > > [...] > > > That is misrepresenting what happened. > > No, it's you who are spreading misinformation, probably unintentional, > but still. Way to go, Sergey.

Re: [PATCH] test_must_be_empty: simplify file existence check

On Mon, Mar 26, 2018 at 2:48 PM, Jeff King wrote: > On Mon, Mar 26, 2018 at 01:58:15PM +0200, SZEDER Gábor wrote: > >> Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not >> just empty, 2018-02-27) basically duplicated the 'test_path_is_file' >> helper function in

Re: [PATCH] test_must_be_empty: simplify file existence check

On Mon, Mar 26, 2018 at 01:58:15PM +0200, SZEDER Gábor wrote: > Commit ea3c87d0b7 (test_must_be_empty: make sure the file exists, not > just empty, 2018-02-27) basically duplicated the 'test_path_is_file' > helper function in 'test_must_be_empty'. > > Just call 'test_path_is_file' to avoid this

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

On Sun, Mar 25, 2018 at 5:15 PM Ævar Arnfjörð Bjarmason wrote: > This looks good to me this time around, couple of small nits (maybe > Junio can amend while queuing): > * You add a dependnecy typo in 2/3 but fix it again in 3/3. Should be > squashed. d'oh, I'll fix that

Cześć słodka

Am Wes ze Stanów Zjednoczonych, ale obecnie przebywa w Syrii na misji pokojowej. Obecnie szukam przyjaźni, która doprowadzi do związku, w którym znowu czuję się kochana ... Chcę cię lepiej poznać, jeśli mogę być odważny. Uważam się za łatwego człowieka .. Proszę wybaczyć moje

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

On Mon, Mar 26 2018, Daniel Jacques wrote: > On Sun, Mar 25, 2018 at 5:15 PM Ævar Arnfjörð Bjarmason > wrote: > >> This looks good to me this time around, couple of small nits (maybe >> Junio can amend while queuing): > >> * You add a dependnecy typo in 2/3 but fix it again

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

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

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 because you try to figure out

[RFC 1/1] packed-backend: ignore broken headers

Prior to 9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data, 2017-07-01 we silently ignored any lines in a `packed-refs` file that we didn't understand. That policy was clearly wrong. But at the time, unrecognized header lines were processed by the same code as

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

Hi Sergey, On Wed, 14 Mar 2018, Sergey Organov wrote: > Igor Djordjevic writes: > > > On 07/03/2018 08:26, Johannes Schindelin wrote: > > [...] > > >> Second side note: if we can fast-forward, currently we prefer that, > >> and I think we should keep that

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,

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: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [PATCH] completion: clear cached --options when sourcing the completion script

On Fri, Mar 23, 2018 at 6:35 PM, Junio C Hamano wrote: > Junio C Hamano writes: >> I'd say we should just add !GETTEXT_POISON prereq to the problematic >> tests. > IOW, this is the minumum required. Thanks for already committing the fix, I couldn't get

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

Thanks for Cc-ing me, and sorry for not being very responsive these days :-\. Jeff King writes: > On Fri, Mar 23, 2018 at 10:40:34PM +, Aaron Greenberg wrote: > >> I can appreciate Matthieu's points on the use of "-" in destructive >> commands. As of this writing, git-merge supports the "-"

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

Prior to 9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data, 2017-07-01 we silently ignored pretty much any bogus data in a `packed-refs` file. I think that was pretty clearly a bad policy. The above commit made parsing quite a bit stricter, calling `die()` if it found

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

On Mon, Mar 26, 2018 at 2:01 AM Junio C Hamano wrote: > When testing the non-relocatable (i.e. traditional) Git, we use > GIT_EXEC_PATH and bin-wrappers/ trick to ensure that we test the > version we just have built, not a random version that happen to be > on the $PATH,

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

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

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

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

[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

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

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

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

[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

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

[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

[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

  1   2   >