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 +482,7 @@ static int chec
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 application that wants to bund
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 might be useful?
>
> Ye
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
> - co
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 Coverity[1]
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 - this was a user
> > er
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 change
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 stash is not fully converted to C, I
>
> 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 'working-tree-encoding' attri
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
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. However, I recall I was told by
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 final
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 patches build on top of the recount fixes in [1]. The commit
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) and basic commit met
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]
> > ; Here we comme
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
> > >
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 th
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 command line to
>> > generate it.
>>
>> It's a good
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 deletions(-)
> > rename t/{t1300-r
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 an
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 bug
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 nor
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).
> >
> >
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
> > th
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
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, we
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.
Does Git need to
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
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 have exactly zero experience
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 t
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;
> + else
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 "git worktree add " kicks
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. Avoid that unnecessary
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
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 anything, unless the '--for
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 F
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.
>
> Thanks, it appears to cove
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 git_co
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:
>> > >
>> > > [
>> > >
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 day
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 users as to what a `pick` is
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 it's not such a go
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 about the
>> > discussion regarding the new recreate-m
Joel Teichroeb writes:
> +static int do_clear_stash(void)
> +{
> + struct object_id obj;
> + if (get_oid(ref_stash, &obj))
> + return 0;
> + return delete_ref(NULL, ref_stash, &obj, 0);
> +}
Here you see if the "refs/stash" is there, and learn what its
current value is, u
Æ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. "The port to my favo
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 experience with these things, nothing will convince
>> > you
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
>> > > (invalid) config behind:
>> > >
>> >
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 this function, so there
was no need to do
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 best way to start would be t
On Thu, Mar 29, 2018 at 04:57:26PM +0200, Duy Nguyen wrote:
> On Wed, Mar 28, 2018 at 02:19:32PM -0400, Jeff King wrote:
> >
> > > I will probably rework on top of your chdir-notify instead (and let
> > > yours to be merged earlier)
> >
> > Thanks. I like some of the related changes you made, li
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 anot
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: expose enumerated repo info", 2017-11-12),
> candidate was an o
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 they do exist in th
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 include:
> output
On Fri, Mar 30, 2018 at 09:00:05AM -0700, Junio C Hamano wrote:
> 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 com
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, free() is wrong in the first place, and FR
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]: set_wo
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 r
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 c
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 by
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 insertions(+), 7 deletions(-)
diff --git a/trace.c b/trace.c
inde
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 s
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 and
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 obscure edge cases lik
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
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 --unset abc.a` on this file,
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
> > trust myself to be unbiased beca
Æ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 get around this
> pr
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 some pointers so you can fix
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. Making shell faster on window
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.
>
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, CONFI
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, instead of giving the re
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 me, all fields should be valid after
>> check_repository_f
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
> func
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, such as better
> control ove
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 ;-)
:)
> > Yeah, I'll wait to see how your refactor
On Fri, Mar 30, 2018 at 02:34:25PM -0400, Jeff King wrote:
> 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: di
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
> ---
> trace.c | 14 +++---
> trace.h | 1 +
> 2 fi
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" meaning...? GIT_TRACE_SETUP?
I think "based on trace_setup_key".
-Peff
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" meaning...? GIT_TRACE_SETUP?
>
> I think "based on t
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 ;-)
>
> :)
>
>> > Yeah, I'l
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 so that we can print traces based on this key outsi
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 n
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 know to dig around i
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 values are parsed cor
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/ ?
> Signed-off-by: Taylor Blau
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. T
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 pa
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Git 2.17 final is expected to be t
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 "packfile.h"
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 to
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 add_opt
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 delt
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 d
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 t
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 oe_size()
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 c
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.
Not listed in the a
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 apply the downstream comm
1 - 100 of 113 matches
Mail list logo
