On Fri, Mar 30, 2018 at 10:48 PM, Jeff King wrote:
> 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
>> +++
On Fri, Mar 30, 2018 at 10:59 PM, Jeff King wrote:
> 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
On Fri, Mar 30, 2018 at 11:04 PM, Jeff King wrote:
> The subject says "clarify" so I was a little surprised to see code
> changes. It looks like we're just avoiding reassigning on top of the
> value repeatedly, which is part of that clarification. It looks like a
> noop to me.
Oh
On Fri, Mar 30, 2018 at 11:24 PM, Jeff King wrote:
> On Sat, Mar 24, 2018 at 07:33:52AM +0100, Nguyễn Thái Ngọc Duy wrote:
>> @@ -2004,10 +2006,12 @@ static int try_delta(struct unpacked *trg, struct
>> unpacked *src,
>> delta_buf = create_delta(src->index, trg->data,
On Fri, Mar 30, 2018 at 11:26 PM, Jeff King wrote:
> 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
Greetings,
Please find the content of this mail very confidential. my name is Yi Tan,
I work with a Bank here in Hong Kong. I decided to contact you for an
opportunity to invest in any lucrative business in your country, I am
willing to offer you 40% as my business partner.
We also offer a quick
--
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
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
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
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:
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
On 3/30/2018 4:38 PM, Junio C Hamano wrote:
* jh/json-writer (2018-03-28) 1 commit
- json_writer: new routines to create data in JSON format
Is this ready for 'next'?
Yes, I believe it is. This has the V6 fixup for the HEREDOC
with leading whitespace, so I think we're good.
Thanks
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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/ ?
>
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
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
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
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
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 ;-)
>
> :)
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"
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
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
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:
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 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,
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
>
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
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,
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,
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.
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.
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
Æ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
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
> >
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
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
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
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
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
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
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
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
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]:
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
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,
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,
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
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
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:
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
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,
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
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
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
>> > >
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
Æ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.
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
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
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
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
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
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 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
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.
>
>
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
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
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:
> > 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.
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
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;
> +
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
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
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
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.
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,
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
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
> >
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).
> >
> >
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
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
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
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
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
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
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 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]
> >
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)
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
1 - 100 of 114 matches
Mail list logo