Re: [PATCH v4 00/13] Serialized Git Commit Graph

I hope that I am addressing the most recent version of this series. Derrick Stolee writes: > As promised [1], this patch contains a way to serialize the commit graph. > The current implementation defines a new file format to store the graph > structure (parent relationships)

[PATCH] setup.c: reset candidate->work_tree after freeing it

Dangling pointers are usually bad news. Reset it back to NULL. Signed-off-by: Nguyễn Thái Ngọc Duy --- setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/setup.c b/setup.c index 7287779642..d193bee192 100644 --- a/setup.c +++ b/setup.c @@ -482,7

Re: Why don't we symlink libexec/git-core/* to bin/git?

Hi Duy, On Fri, 16 Mar 2018, Duy Nguyen wrote: > On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin > wrote: > > To add some interesting information to this: in MinGit (the > > light-weight "Git for applications" we bundle to avoid adding a hefty > > 230MB to any

Re: [ANNOUNCE] Git v2.17.0-rc2

Hi team, On Wed, 28 Mar 2018, Junio C Hamano wrote: > A release candidate Git v2.17.0-rc2 is now available for testing > at the usual places. It is comprised of 499 non-merge commits > since v2.16.0, contributed by 62 people, 19 of which are new faces. > > I am hoping that we can have the

Re: Draft of Git Rev News edition 37

Hi, On Mon, 19 Mar 2018, Christian Couder wrote: > On Sun, Mar 18, 2018 at 11:41 PM, Jacob Keller wrote: > > > > I don't have a good summary yet, but I think a section about the > > discussion regarding the new recreate-merges and rebasing merges > > that's been on going

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

Hi Thomas, On Mon, 26 Mar 2018, Thomas Gummerer wrote: > On 03/26, Johannes Schindelin wrote: > > > > On Sun, 25 Mar 2018, Eric Sunshine wrote: > > > > > On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu > > > wrote: > > > > Currently, because git

Re: core.fsmonitor always perform rescans

Hi, On Mon, 26 Mar 2018, Tatsuyuki Ishi wrote: > I'm facing issue with core.fsmonitor. > > I'm currently using the provided watchman hook, but it doesn't seem to > record the fact that it has queried the fsmonitor backend, and as a > result the timestamp passed to the hook doesn't seem to

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

Hi Stefan, On Thu, 29 Mar 2018, Stefan Beller wrote: > On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin > wrote: > > > So what is the argument against this extra care to detect comments? Well, if > > you have something like this: > > > > [section] > >

Re: What's cooking in git.git (Mar 2018, #05; Wed, 28)

On Wed, Mar 28 2018, Junio C. Hamano wrote: > * ls/checkout-encoding (2018-03-16) 10 commits > - convert: add round trip check based on 'core.checkRoundtripEncoding' > - convert: add tracing for 'working-tree-encoding' attribute > - convert: check for detectable errors in UTF encodings > -

Re: [PATCH v6 0/6] ref-filter: remove die() calls from formatting logic

2018-03-29 17:41 GMT+03:00 Christian Couder : > On Thu, Mar 29, 2018 at 2:52 PM, Оля Тележная > wrote: >> Move helper function from strbuf to ref-filter. >> Get rid of some memory leaks. > > The above seems to be the changes since v5. Usually

Re: What's cooking in git.git (Mar 2018, #05; Wed, 28)

> On 30 Mar 2018, at 11:24, Ævar Arnfjörð Bjarmason wrote: > > > On Wed, Mar 28 2018, Junio C. Hamano wrote: > >> * ls/checkout-encoding (2018-03-16) 10 commits >> - convert: add round trip check based on 'core.checkRoundtripEncoding' >> - convert: add tracing for

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

Hi, On Thu, 29 Mar 2018, Sergey Organov wrote: > Jacob Keller writes: > > > I care about the general compatibility of the rebase todo list > > regardless of which options you enabled on the command line to > > generate it. > > It's a good thing in general, yes.

Re: Bad refspec messes up bundle.

Hi Luciano, On Mon, 19 Mar 2018, Junio C Hamano wrote: > Luciano Joublanc writes: > > > Yesterday I created a git bundle as best as I can remember like this > > > > git bundle save chunk chunk.bundle --all master > > > > Note the 'master' I added accidentally at the end

Re: [RFC PATCH 0/1] bdl-lib.sh: add bash debug logger

Hi Wink, On Tue, 27 Mar 2018, Wink Saville wrote: > Add bdl-lib.sh which provides functions to assit in debugging git > shell scripts and tests. Interesting idea. It is Bash-only, though... (and it is not a secret that I want to discourage using Unix shell scripts in Git's production code, they

[PATCH] {fetch,upload}-pack: clearly mark unreachable v2 code

Change the switch statement driving upload_pack_v2() and do_fetch_pack_v2() to clearly indicate that the FETCH_DONE case is being handled implicitly by other code, instead of giving the reader the impression that the "continue" statement is needed. This issue was flagged as DEADCODE by

Re: [PATCH v3 0/3] add -p: select individual hunk lines

On 29/03/18 19:32, Junio C Hamano wrote: > Phillip Wood writes: > >> From: Phillip Wood >> >> Since v2 I've updated the patches to use '-' instead of '^' to invert >> the selection to match the rest of add -i and clean -i. >> >> These

Re: [PATCH 1/9] git_config_set: fix off-by-two

Hi, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote: > > > > When calling `git config --unset abc.a` on this file, it leaves this > > > (invalid) config behind: > > > > > > [ > > > [xyz] > > > key = value > >

Re: [PATCH v5 0/6] worktree: teach "add" to check out existing branches

On 03/27, Eric Sunshine wrote: > On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > > Thanks Eric for the review of the previous round and Duy and Junio for > > additional comments. > > This round should address all of Eric's comments from the previous round. > >

Re: [PATCH 1/9] git_config_set: fix off-by-two

On Fri, Mar 30 2018, Johannes Schindelin wrote: > On Thu, 29 Mar 2018, Jeff King wrote: > >> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote: >> >> > > When calling `git config --unset abc.a` on this file, it leaves this >> > > (invalid) config behind: >> > > >> > > [ >> >

Re: [PATCH 7/9] git config --unset: remove empty sections (in normal situations)

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:19:00PM +0200, Johannes Schindelin wrote: > > > Let's generalize this observation to this conservative strategy: if we > > are removing the last entry from a section, and there are no comments > > inside that section

Re: [PATCH 7/9] git config --unset: remove empty sections (in normal situations)

On Fri, Mar 30, 2018 at 03:00:06PM +0200, Johannes Schindelin wrote: > > I guess the holy grail would be a parser which reports _all_ syntactic > > events (section names, keys, comments, whitespace, etc) as a stream > > without storing anything. And then the normal reader could just discard > >

Re: [PATCH 8/9] git_config_set: use do_config_from_file() directly

On Fri, Mar 30, 2018 at 03:02:00PM +0200, Johannes Schindelin wrote: > > I'm not sure I understand that last paragraph. What does flockfile() have > > to do with stdin/stdout? > > > > The point of those calls is that we're locking the FILE handle, so that > > it's safe for the lower-level config

Re: [PATCH 8/9] git_config_set: use do_config_from_file() directly

Hi Peff, On Fri, 30 Mar 2018, Jeff King wrote: > On Fri, Mar 30, 2018 at 03:02:00PM +0200, Johannes Schindelin wrote: > > > > I'm not sure I understand that last paragraph. What does flockfile() have > > > to do with stdin/stdout? > > > > > > The point of those calls is that we're locking the

Re: [PATCH 8/9] git_config_set: use do_config_from_file() directly

On Fri, Mar 30, 2018 at 04:01:56PM +0200, Johannes Schindelin wrote: > You know what is *really* funny? > > -- snip -- > static int git_config_from_stdin(config_fn_t fn, void *data) > { > return do_config_from_file(fn, CONFIG_ORIGIN_STDIN, "", NULL, stdin, > data, 0); > } > > int

Re: [PATCH 4/9] t1300: remove unreasonable expectation from TODO

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:18:50PM +0200, Johannes Schindelin wrote: > > > In https://public-inbox.org/git/7vvc8alzat@alter.siamese.dyndns.org/ > > a reasonable patch was made quite a bit less so by changing a test case > > demonstrating a

Re: [PATCH 9/9] git_config_set: reuse empty sections

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:19:09PM +0200, Johannes Schindelin wrote: > > > It can happen quite easily that the last setting in a config section is > > removed, and to avoid confusion when there are comments in the config > > about that section,

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

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > > On Fri, 30 Mar 2018, Sergey Organov wrote: > >> Could we please agree to stop using backward compatibility as an >> objection in the discussion of the --recreate-merges feature? > > No. > > The expectation of

Re: [PATCH v4 01/13] commit-graph: add format document

Derrick Stolee writes: > +== graph-*.graph files have the following format: What is this '*' here? [...] > + The remaining data in the body is described one chunk at a time, and > + these chunks may be given in any order. Chunks are required unless > + otherwise specified.

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

Hi Sergey, On Fri, 30 Mar 2018, Sergey Organov wrote: > Could we please agree to stop using backward compatibility as an > objection in the discussion of the --recreate-merges feature? No. The expectation of users as to what a `pick` is has not changed just because you wish it would. That is

Re: [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Fri, Mar 30, 2018 at 01:27:19AM -0400, Taylor Blau wrote: > > If you really want to go all-out, I think the ACTION flags could use the > > same cleanup. We treat them as bitflags, and then issue an error when > > you set more than one, which is just silly. > > Agreed, and I think that this is

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

On Thu, Mar 29 2018, Johannes Schindelin wrote: > Nonetheless, I would be confortable with this patch going into v2.17.0, even > at > this late stage. The final verdict is Junio's, of course. Thanks a lot for working on this. I'm keen to stress test this, but won't have time in the next few

Re: [PATCH 2/9] t1300: rename it to reflect that `repo-config` was deprecated

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:18:40PM +0200, Johannes Schindelin wrote: > > > Signed-off-by: Johannes Schindelin > > --- > > t/{t1300-repo-config.sh => t1300-config.sh} | 0 > > 1 file changed, 0 insertions(+), 0

Re: [PATCH 3/9] t1300: avoid relying on a bug

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:18:45PM +0200, Johannes Schindelin wrote: > > > The test case 'unset with cont. lines' relied on a bug that is about to > > be fixed: it tests *explicitly* that removing the last entry from a > > config section leaves

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

Hi Sergey, On Wed, 28 Mar 2018, Sergey Organov wrote: > Johannes Schindelin writes: > > > I use rebase every day. I use the Git garden shears every week. If you > > do not trust my experience with these things, nothing will convince > > you. > > Unfortunately you

Re: [PATCH v5 3/6] worktree: remove force_new_branch from struct add_opts

On 03/27, Eric Sunshine wrote: > On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > > The 'force_new_branch' flag in 'struct add_opts' is only used inside the > > add function, where we already have the same information stored in the > > 'new_branch_force' variable.

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:18:30PM +0200, Johannes Schindelin wrote: > > > The first patch is somewhat of a "while at it" bug fix that I first > > thought would be a lot more critical than it actually is: It really > > only affects config files

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

Hi Johannes, Johannes Schindelin writes: > Hi, > > On Thu, 29 Mar 2018, Sergey Organov wrote: > >> Jacob Keller writes: >> >> > I care about the general compatibility of the rebase todo list >> > regardless of which options you enabled on the

Re: [PATCH v2 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Fri, Mar 30, 2018 at 01:28:30AM -0400, Taylor Blau wrote: > +static int option_parse_type(const struct option *opt, const char *arg, > + int unset) > +{ > + int *type = opt->value; > + > + if (!strcmp(arg, "bool")) > + *type = TYPE_BOOL; > +

Re: [PATCH v5 5/6] worktree: teach "add" to check out existing branches

On 03/27, Eric Sunshine wrote: > On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > > Currently 'git worktree add ' creates a new branch named after the > > basename of the path by default. If a branch with that name already > > exists, the command refuses to do

Re: [PATCH 8/9] git_config_set: use do_config_from_file() directly

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:19:04PM +0200, Johannes Schindelin wrote: > > > Technically, it is the git_config_set_multivar_in_file_gently() > > function that we modify here (but the oneline would get too long if we > > were that precise). > > > >

Re: [PATCH v2 1/2] builtin/config.c: treat type specifiers singularly

On Fri, Mar 30, 2018 at 01:28:29AM -0400, Taylor Blau wrote: > Internally, we represent `git config`'s type specifiers as a bitset > using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique > allows for the representation of multiple type specifiers in the `int > types` field, but

Re: [PATCH v5 2/6] worktree: be clearer when "add" dwim-ery kicks in

On 03/27, Eric Sunshine wrote: > On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > > Currently there is no indication in the "git worktree add" output that > > a new branch was created. This would be especially useful information > > in the case where the dwim of

Re: Draft of Git Rev News edition 37

On Fri, Mar 30, 2018 at 2:02 AM, Johannes Schindelin wrote: > Hi, > > On Mon, 19 Mar 2018, Christian Couder wrote: > >> On Sun, Mar 18, 2018 at 11:41 PM, Jacob Keller >> wrote: >> > >> > I don't have a good summary yet, but I think a section

Re: Bad refspec messes up bundle.

Johannes Schindelin writes: > Hi Luciano, > >> > Is this a bug? Should bundle allow providing multiple refspecs when > ... > I agree that it is a bug if a bundle file records a ref multiple times. > Luciano, here are some pointers so you can fix it: > > - probably the

[PATCH v2 5/5] refs: use chdir_notify to update cached relative paths

Commit f57f37e2e1 (files-backend: remove the use of git_path(), 2017-03-26) introduced a regression when a relative $GIT_DIR is used in a working tree: - when we initialize the ref backend, we make a copy of get_git_dir(), which may be relative - later, we may call setup_work_tree() and

[PATCH v2 2/5] trace.c: export trace_setup_key

From: Nguyễn Thái Ngọc Duy This is so that we can print traces based on this key outside trace.c. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Jeff King --- trace.c | 14 +++--- trace.h | 1 + 2 files changed, 8

[PATCH v2 4/5] set_work_tree: use chdir_notify

When we change to the top of the working tree, we manually re-adjust $GIT_DIR and call set_git_dir() again, in order to update any relative git-dir we'd compute earlier. Instead of the work-tree code having to know to call the git-dir code, let's use the new chdir_notify interface. There are two

[PATCH v2 0/5] re-parenting relative directories after chdir

On Wed, Mar 28, 2018 at 01:36:56PM -0400, Jeff King wrote: > For those just joining us, this fixes a regression that was in v2.13 (so > nothing we need to worry about as part of the 2.17-rc track). > > [1/4]: set_git_dir: die when setenv() fails > [2/4]: add chdir-notify API > [3/4]:

[PATCH v2 1/5] set_git_dir: die when setenv() fails

The set_git_dir() function returns an error if setenv() fails, but there are zero callers who pay attention to this return value. If this ever were to happen, it could cause confusing results, as sub-processes would see a potentially stale GIT_DIR (e.g., if it is relative and we chdir()-ed to the

[PATCH v2 3/5] add chdir-notify API

If one part of the code does a permanent chdir(), then this invalidates any relative paths that may be held by other parts of the code. For example, setup_work_tree() moves us to the top of the working tree, which may invalidate a previously stored relative gitdir. We've hacked around this case

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

Joel Teichroeb writes: > +static int do_clear_stash(void) > +{ > + struct object_id obj; > + if (get_oid(ref_stash, )) > + return 0; > + return delete_ref(NULL, ref_stash, , 0); > +} Here you see if the "refs/stash" is there, and learn what its

Re: [PATCH 1/9] git_config_set: fix off-by-two

Ævar Arnfjörð Bjarmason writes: > I think if it's worth fixing it's worth testing for, a future change to > the config code could easily introduce a regression for this, and > particularly in this type of code obscure edge cases like this can point > to bugs elsewhere. Yup.

Re: [PATCH 1/9] git_config_set: fix off-by-two

On Fri, Mar 30, 2018 at 2:32 PM, Johannes Schindelin wrote: > Hi, > > On Thu, 29 Mar 2018, Jeff King wrote: > >> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote: >> >> > > When calling `git config --unset abc.a` on this file, it leaves this >> > >

Re: [PATCH] setup.c: reset candidate->work_tree after freeing it

Duy Nguyen writes: > On Fri, Mar 30, 2018 at 7:10 PM, Junio C Hamano wrote: > >> Which fields in candidate are safe to peek by the caller? How can a >> caller tell? > > To me, all fields should be valid after > check_repository_format_gently(). If so,

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

Hi Ævar, On Fri, 30 Mar 2018, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Mar 29 2018, Johannes Schindelin wrote: > > > Nonetheless, I would be confortable with this patch going into > > v2.17.0, even at this late stage. The final verdict is Junio's, of > > course. > > Thanks a lot for working

Re: [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

Jeff King writes: > ... But actually, last-one-wins applies only > to a _single_ option, not necessarily unrelated ones. Many other > multi-action commands actually have a series of separate boolean flags, > and then complain when more than one of the flags is set. > > So maybe

Re: [PATCH 3/4] set_work_tree: use chdir_notify

On Thu, Mar 29, 2018 at 08:01:33PM +0200, Duy Nguyen wrote: > > I do kind of like that. I'm reasonably happy with the chdir_notify() > > interface, but it would be nicer still if we could get rid of it in the > > first place. It's true that we _could_ chdir from other places, but > > There's

Re: [PATCH v3 1/3] builtin/config: introduce `--default`

Taylor Blau writes: > For some use cases, callers of the `git-config(1)` builtin would like to > fallback to default values when the slot asked for does not exist. In > addition, users would like to use existing type specifiers to ensure > that values are parsed correctly when

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

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > > On Wed, 28 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin writes: >> >> > I use rebase every day. I use the Git garden shears every week. If you >> > do not trust my

Re: [PATCH] setup.c: reset candidate->work_tree after freeing it

Nguyễn Thái Ngọc Duy writes: > Dangling pointers are usually bad news. Reset it back to NULL. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- Before abade65b ("setup: expose enumerated repo info", 2017-11-12), candidate was an on-stack variable local to

Re: [PATCH v3 3/3] builtin/config: introduce `color` type specifier

Taylor Blau writes: > @@ -184,6 +183,7 @@ Valid `[type]`'s include: > --bool-or-int:: > --path:: > --expiry-date:: > +--color:: >Historical options for selecting a type specifier. Prefer instead `--type`, >(see: above). > > @@ -223,6 +223,9 @@ Valid `[type]`'s

Re: Draft of Git Rev News edition 37

Hi Jake, On Fri, 30 Mar 2018, Jacob Keller wrote: > On Fri, Mar 30, 2018 at 2:02 AM, Johannes Schindelin > wrote: > > > > Jake, I do not know about your availability, but I would love it if > > you could take a stab, as I trust you to be unbiased. I would not > >

Re: [PATCH 8/9] git_config_set: use do_config_from_file() directly

Hi Peff, On Fri, 30 Mar 2018, Jeff King wrote: > On Fri, Mar 30, 2018 at 04:01:56PM +0200, Johannes Schindelin wrote: > > > You know what is *really* funny? > > > > -- snip -- > > static int git_config_from_stdin(config_fn_t fn, void *data) > > { > > return do_config_from_file(fn,

Re: [PATCH] {fetch,upload}-pack: clearly mark unreachable v2 code

On Fri, Mar 30, 2018 at 12:03 PM, Brandon Williams wrote: > On 03/30, Ævar Arnfjörð Bjarmason wrote: >> Change the switch statement driving upload_pack_v2() and >> do_fetch_pack_v2() to clearly indicate that the FETCH_DONE case is >> being handled implicitly by other code,

Re: [PATCH] setup.c: reset candidate->work_tree after freeing it

On Fri, Mar 30, 2018 at 7:10 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> Dangling pointers are usually bad news. Reset it back to NULL. >> >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- > > Before abade65b ("setup:

A potential approach to making tests faster on Windows

On Fri, Mar 30 2018, Johannes Schindelin wrote [expressing frustrations about Windows test suite slowness]: I've wondered for a while whether it wouldn't be a viable approach to make something like an interpreter for our test suite to get around this problem, i.e. much of it's very repetitive

Re: [PATCH 1/9] git_config_set: fix off-by-two

Hi Junio, On Fri, 30 Mar 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > I think if it's worth fixing it's worth testing for, a future change to > > the config code could easily introduce a regression for this, and > > particularly in this type of code

Re: [PATCH 1/9] git_config_set: fix off-by-two

Hi Duy, On Fri, 30 Mar 2018, Duy Nguyen wrote: > On Fri, Mar 30, 2018 at 2:32 PM, Johannes Schindelin > wrote: > > > > On Thu, 29 Mar 2018, Jeff King wrote: > > > >> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote: > >> > >> > > When calling `git config

Re: Bad refspec messes up bundle.

Hi Junio, On Fri, 30 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> > Is this a bug? Should bundle allow providing multiple refspecs when > > ... > > I agree that it is a bug if a bundle file records a ref multiple > > times. Luciano, here are

Re: A potential approach to making tests faster on Windows

Ævar Arnfjörð Bjarmason writes: > On Fri, Mar 30 2018, Johannes Schindelin wrote [expressing frustrations > about Windows test suite slowness]: > > I've wondered for a while whether it wouldn't be a viable approach to > make something like an interpreter for our test suite to

Re: [PATCH 1/9] git_config_set: fix off-by-two

Johannes Schindelin writes: > What would be a *really* good strategy is: "Oh, there is a problem! Let's > acknowledge it and try to come up with a solution rather than a > work-around". > > EXPENSIVE_ON_WINDOWS is a symptom. Not a solution. Yes, it is a workaround.

Re: [PATCH] {fetch,upload}-pack: clearly mark unreachable v2 code

On 03/30, Ævar Arnfjörð Bjarmason wrote: > Change the switch statement driving upload_pack_v2() and > do_fetch_pack_v2() to clearly indicate that the FETCH_DONE case is > being handled implicitly by other code, instead of giving the reader > the impression that the "continue" statement is needed.

Re: [PATCH] setup.c: reset candidate->work_tree after freeing it

On Fri, Mar 30, 2018 at 8:32 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Fri, Mar 30, 2018 at 7:10 PM, Junio C Hamano wrote: >> >>> Which fields in candidate are safe to peek by the caller? How can a >>> caller tell? >> >> To

Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)

On 03/30, Junio C Hamano wrote: > * tg/worktree-add-existing-branch (2018-03-27) 6 commits > - t2025: rename now outdated branch name > - worktree: teach "add" to check out existing branches > - worktree: factor out dwim_branch function > - worktree: remove force_new_branch from struct

Re: [GSoC][PATCH v5] test: avoid pipes in git related commands for test

Eric Sunshine writes: > On Tue, Mar 27, 2018 at 1:31 PM, Pratik Karki wrote: >> Avoid using pipes downstream of Git commands since the exit codes >> of commands upstream of pipes get swallowed, thus potentially >> hiding failure of those

Re: [RFC PATCH 0/1] bdl-lib.sh: add bash debug logger

On Fri, Mar 30, 2018 at 3:34 AM, Johannes Schindelin wrote: > Hi Wink, > > On Tue, 27 Mar 2018, Wink Saville wrote: > >> Add bdl-lib.sh which provides functions to assit in debugging git >> shell scripts and tests. > > Interesting idea. It is Bash-only, though... (and

[PATCH] fast-import: fix a sparse 'NULL pointer' warning

Commit a8dfa11562 ("fast-import: introduce mem_pool type", 2018-03-26) introduces a 'mem_pool' type, along with a file-local global symbol ('fi_mem_poll') which is initialised in its declaration. This causes sparse to issue a warning, thus: SP fast-import.c fast-import.c:301:40: warning:

Re: [PATCH 1/9] git_config_set: fix off-by-two

On Fri, Mar 30, 2018 at 8:53 PM, Johannes Schindelin wrote: > I think the best course of action would be to incrementally do away with > the shell scripted test framework, in the way you outlined earlier this > year. This would *also* buy us a wealth of other benefits,

Re: [PATCH v2 2/5] trace.c: export trace_setup_key

Jeff King writes: > From: Nguyễn Thái Ngọc Duy > > This is so that we can print traces based on this key outside trace.c. "this key" meaning...? GIT_TRACE_SETUP? > > Signed-off-by: Nguyễn Thái Ngọc Duy > Signed-off-by: Jeff King

Re: [PATCH v7 05/13] pack-objects: move in_pack_pos out of struct object_entry

On Sat, Mar 24, 2018 at 07:33:45AM +0100, Nguyễn Thái Ngọc Duy wrote: > This field is only need for pack-bitmap, which is an optional > feature. Move it to a separate array that is only allocated when > pack-bitmap is used (it's not freed in the same way that objects[] is > not). I had trouble

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

On Sat, Mar 24, 2018 at 07:33:46AM +0100, Nguyễn Thái Ngọc Duy wrote: > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c > index e1244918a5..b41610569e 100644 > --- a/builtin/pack-objects.c > +++ b/builtin/pack-objects.c > @@ -29,6 +29,8 @@ > #include "list.h" > #include

Re: [PATCH v7 07/13] pack-objects: refer to delta objects by index instead of pointer

On Sat, Mar 24, 2018 at 07:33:47AM +0100, Nguyễn Thái Ngọc Duy wrote: > These delta pointers always point to elements in the objects[] array > in packing_data struct. We can only hold maximum 4G of those objects > because the array size in nr_objects is uint32_t. We could use > uint32_t indexes

Re: [PATCH v7 10/13] pack-objects: clarify the use of object_entry::size

On Sat, Mar 24, 2018 at 07:33:50AM +0100, Nguyễn Thái Ngọc Duy wrote: > While this field most of the time contains the canonical object size, > there is one case it does not: when we have found that the base object > of the delta in question is also to be packed, we will very happily > reuse the

Re: [PATCH v7 12/13] pack-objects: shrink delta_size field in struct object_entry

On Sat, Mar 24, 2018 at 07:33:52AM +0100, Nguyễn Thái Ngọc Duy wrote: > Allowing a delta size of 64 bits is crazy. Shrink this field down to > 31 bits with one overflow bit. > > If we find an existing delta larger than 2GB, we do not cache > delta_size at all and will get the value from

Re: [PATCH v7 13/13] pack-objects: reorder members to shrink struct object_entry

On Sat, Mar 24, 2018 at 07:33:53AM +0100, Nguyễn Thái Ngọc Duy wrote: > Previous patches leave lots of holes and padding in this struct. This > patch reorders the members and shrinks the struct down to 80 bytes > (from 136 bytes, before any field shrinking is done) with 16 bits to > spare (and a

Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)

Junio C Hamano writes: > -- > [Graduated to "master"] > > * jh/partial-clone (2018-03-25) 1 commit > (merged to 'next' on 2018-03-28 at 2a0a7aef8e) > + unpack-trees: release oid_array after use in check_updates() > > Hotfix.

Re: [PATCH] fast-import: fix a sparse 'NULL pointer' warning

Ramsay Jones writes: > This was going to be an email to Jameson, but I wasn't fast enough! :( > > This was originally written against the 'pu' branch, but since the > 'jm/mem-pool' branch has graduated to 'next', I have rebased on 'next'. > > Perhaps this could be

Compliment of the day ,

-- Hi dear. It is wonderful to contact you, I want us to have correspondence. I wish you will have the desire so that we can get acquainted to each other. Life itself is a mystery, you never know where it might lead you. I'm Tracy.William, a French American . I will be pleased if you reply

Re: [PATCH] config: move flockfile() closer to unlocked functions

Jeff King writes: > On Fri, Mar 30, 2018 at 09:04:13PM +0200, Johannes Schindelin wrote: > >> > Probably the flockfile should go into do_config_from_file(), where we >> > specify to use the unlocked variants. >> >> Ah, that makes sense now! I am glad I could also help ;-) > > :)

Re: [PATCH v7 03/13] pack-objects: use bitfield for object_entry::dfs_state

On Sat, Mar 24, 2018 at 07:33:43AM +0100, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- This probably needs some explanation for people digging in history (even if it's "this is to shrink the size as part of a larger struct-shrinking effort" so they

Re: [PATCH v3 1/3] builtin/config: introduce `--default`

On Wed, Mar 28, 2018 at 9:16 PM, Taylor Blau wrote: > For some use cases, callers of the `git-config(1)` builtin would like to > fallback to default values when the slot asked for does not exist. In > addition, users would like to use existing type specifiers to ensure > that

Re: [PATCH v7 08/13] pack-objects: shrink z_delta_size field in struct object_entry

On Sat, Mar 24, 2018 at 07:33:48AM +0100, Nguyễn Thái Ngọc Duy wrote: > We only cache deltas when it's smaller than a certain limit. This limit > defaults to 1000 but save its compressed length in a 64-bit field. > Shrink that field down to 16 bits, so you can only cache 65kb deltas. > Larger

Re: [PATCH v7 11/13] pack-objects: shrink size field in struct object_entry

On Sat, Mar 24, 2018 at 07:33:51AM +0100, Nguyễn Thái Ngọc Duy wrote: > It's very very rare that an uncompressed object is larger than 4GB > (partly because Git does not handle those large files very well to > begin with). Let's optimize it for the common case where object size > is smaller than

Re: A potential approach to making tests faster on Windows

On Fri, Mar 30, 2018 at 08:45:45PM +0200, Ævar Arnfjörð Bjarmason wrote: > I've wondered for a while whether it wouldn't be a viable approach to > make something like an interpreter for our test suite to get around this > problem, i.e. much of it's very repetitive and just using a few shell >

Re: [PATCH v2 2/5] trace.c: export trace_setup_key

Jeff King writes: > On Fri, Mar 30, 2018 at 12:46:26PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > From: Nguyễn Thái Ngọc Duy >> > >> > This is so that we can print traces based on this key outside trace.c. >> >> "this key"

Re: [PATCH v2 2/5] trace.c: export trace_setup_key

On Fri, Mar 30, 2018 at 12:50:50PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Fri, Mar 30, 2018 at 12:46:26PM -0700, Junio C Hamano wrote: > > > >> Jeff King writes: > >> > >> > From: Nguyễn Thái Ngọc Duy > >> > > >> > This is

Re: [PATCH v7 02/13] pack-objects: turn type and in_pack_type to bitfields

On Sat, Mar 24, 2018 at 07:33:42AM +0100, Nguyễn Thái Ngọc Duy wrote: > +static inline void oe_set_type(struct object_entry *e, > +enum object_type type) > +{ > + if (type >= OBJ_ANY) > + die("BUG: OBJ_ANY cannot be set in pack-objects code"); A minor

Re: [PATCH v3 2/3] config.c: introduce 'git_config_color' to parse ANSI colors

On Wed, Mar 28, 2018 at 9:16 PM, Taylor Blau wrote: > In preparation for adding `--color` to the `git-config(1)` builtin, > let's introduce a color parsing utility, `git_config_color` in a similar > fashion to `git_config_`. Did you mean s/--color/--type=color/ ? >

Re: [PATCH v7 04/13] pack-objects: use bitfield for object_entry::depth

On Sat, Mar 24, 2018 at 07:33:44AM +0100, Nguyễn Thái Ngọc Duy wrote: > Because of struct packing from now on we can only handle max depth > 4095 (or even lower when new booleans are added in this struct). This > should be ok since long delta chain will cause significant slow down > anyway. OK.

Re: [GSoC][PATCH v5] test: avoid pipes in git related commands for test

On Tue, Mar 27, 2018 at 1:31 PM, Pratik Karki wrote: > Avoid using pipes downstream of Git commands since the exit codes > of commands upstream of pipes get swallowed, thus potentially > hiding failure of those commands. Instead, capture Git command > output to a file and

  1   2   >