Jeff King writes:
> That said, our C99 designated initializer weather-balloons haven't
> gotten any complaints yet. So I think you could actually do:
>
> struct setup_revision_opt s_r_opt = {
> .allow_exclude_promisor_objects = 1,
> };
> ...
> setup_revisions(...);
>
> which is
On 12/03/2018 01:15 PM, Jeff King wrote:
That said, our C99 designated initializer weather-balloons haven't
gotten any complaints yet. So I think you could actually do:
struct setup_revision_opt s_r_opt = {
.allow_exclude_promisor_objects = 1,
};
I like this way best, so I'll
On Mon, Dec 03, 2018 at 11:10:49AM -0800, Matthew DeVore wrote:
> > > + memset(_r_opt, 0, sizeof(s_r_opt));
> > > + s_r_opt.allow_exclude_promisor_objects = 1;
> > > + setup_revisions(ac, av, , _r_opt);
> >
> > I wonder if a static initializer for setup_revision_opt is worth it. It
> > would
On 12/01/2018 11:44 AM, Jeff King wrote:
repo_init_revisions(the_repository, , NULL);
save_commit_buffer = 0;
- revs.allow_exclude_promisor_objects_opt = 1;
- setup_revisions(ac, av, , NULL);
+
+ memset(_r_opt, 0, sizeof(s_r_opt));
+
On Fri, Nov 30, 2018 at 05:32:47PM -0800, Matthew DeVore wrote:
> > Speaking of which, would this flag work better as a field in
> > setup_revision_opt, which is passed to setup_revisions()? The intent
> > seem to be to influence how we parse command-line arguments, and that's
> > where other
On 11/21/2018 08:40 AM, Jeff King wrote:
On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:
diff --git a/builtin/prune.c b/builtin/prune.c
index 41230f8215..11284d0bf3 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -120,6 +120,7 @@ int cmd_prune(int argc, const char
On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:
> diff --git a/builtin/prune.c b/builtin/prune.c
> index 41230f8215..11284d0bf3 100644
> --- a/builtin/prune.c
> +++ b/builtin/prune.c
> @@ -120,6 +120,7 @@ int cmd_prune(int argc, const char **argv, const char
> *prefix)
>
Matthew DeVore writes:
> On Tue, 23 Oct 2018, Junio C Hamano wrote:
>
>> Not really. We were already doing a controlled failure via die(),
>> so these two tests would not have caught the problem in the code
>> before the fix in this patch.
>>
>
> BUG is apparently considered a "wrong" failure
On Tue, 23 Oct 2018, Junio C Hamano wrote:
Not really. We were already doing a controlled failure via die(),
so these two tests would not have caught the problem in the code
before the fix in this patch.
BUG is apparently considered a "wrong" failure and not a controlled one
by
Matthew DeVore writes:
> t/t4202-log.sh | 4
> t/t8002-blame.sh | 4
> 7 files changed, 14 insertions(+), 1 deletion(-)
> ...
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 153a506151..819c24d10e 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -1703,4
10 matches
Mail list logo
