git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: tanushree27 <tanushreetumane@gmail.com>
Cc: pclouds@gmail.com, git@vger.kernel.org
Subject: Re: [PATCH v3] commit: add a commit.allowEmpty config variable
Date: Sat, 03 Nov 2018 20:07:43 +0100	[thread overview]
Message-ID: <87d0rm7zeo.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20181103151205.29122-1-tanushreetumane@gmail.com>


On Sat, Nov 03 2018, tanushree27 wrote:

> +commit.allowEmpty::
> +	A boolean to specify whether empty commits are allowed with `git
> +	commit`. See linkgit:git-commit[1].
> +	Defaults to false.
> +

Good.

> +	if (config_commit_allow_empty >= 0)  /* if allowEmpty is allowed in config*/
> +		allow_empty = config_commit_allow_empty;
> +

This works, but != -1 is our usual idiom for this as you initialize it
to -1. I think that comment can also go then, since it's clear what's
going on.

> +# Tests for commit.allowEmpty config
> +
> +test_expect_success "no commit.allowEmpty and no --allow-empty" "
> +	test_must_fail git commit -m 'test'
> +"
> +
> +test_expect_success "no commit.allowEmpty and --allow-empty" "
> +	git commit --allow-empty -m 'test'
> +"
> +
> +for i in true 1
> +do
> +	test_expect_success "commit.allowEmpty=$i and no --allow-empty" "
> +		git -c commit.allowEmpty=$i commit -m 'test'
> +	"
> +
> +	test_expect_success "commit.allowEmpty=$i and --allow-empty" "
> +		git -c commit.allowEmpty=$i commit --allow-empty -m 'test'
> +	"
> +done
> +
> +for i in false 0
> +do
> +	test_expect_success "commit.allowEmpty=$i and no --allow-empty" "
> +		test_must_fail git -C commit.allowEmpty=$i commit -m 'test'
> +	"
> +
> +	test_expect_success "commit.allowEmpty=$i and --allow-empty" "
> +		test_must_fail git -c commit.allowEmpty=$i commit --allow-empty -m 'test'
> +	"
> +done

Testing both 1 and "true" can be dropped here. Things that use
git_config_bool() can just assume it works, we test it more exhaustively
elsewhere.

Your patch has whitespace errors. Try with "git show --check" or apply
it with git-am, it also doesn't apply cleanly on the latest master.

But on this patch in general: I don't mind making this configurable, but
neither your commit message nor these tests make it clear what the
actual motivation is, which can be seen on the upstream GitHub bug
report.

I.e. you seemingly have no interest in using "git commit" to produce
empty commits, but are just trying to cherry-pick something and it's
failing because it (presumably, or am I missing something) cherry picks
an existing commit content ends up not changing anything.

I.e. you'd like to make the logic 37f7a85793 ("Teach commit about
CHERRY_PICK_HEAD", 2011-02-19) added a message for the default.

So let's talk about that use case, and for those of us less familiar
with this explain why it is that this needs to still be optional at
all. I.e. aren't we just exposing an implementation detail here where
cherry-pick uses the commit machinery? Should we maybe just always pass
--allow-empty on cherry-pick, if not why not?

I can think of some reasons, but the above is a hint that both this
patch + the current documentation which talks about "foreign SCM
scripts" have drifted very far from what this is actually being used
for, so let's update that.

  reply	other threads:[~2018-11-03 19:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-03 11:25 [PATCH] commit: add a commit.allowEmpty config variable tanushree27
2018-11-03 11:53 ` [[PATCH v2]] commit: add a commit.allowempty " tanushree27
2018-11-03 14:43   ` Duy Nguyen
2018-11-03 15:12     ` [PATCH v3] commit: add a commit.allowEmpty " tanushree27
2018-11-03 19:07       ` Ævar Arnfjörð Bjarmason [this message]
2018-11-05  0:30         ` Junio C Hamano
2018-11-13 15:56         ` [PATCH v4] " Tanushree Tumane
2018-11-13 19:24           ` Johannes Schindelin
2018-11-13 21:27             ` Ævar Arnfjörð Bjarmason
2018-11-14  4:16               ` Junio C Hamano
2018-11-14 14:04                 ` Johannes Schindelin
2018-11-15  8:40                 ` Johannes Schindelin
2018-11-15  9:41                   ` Jeff King
2018-11-15 16:16                     ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0rm7zeo.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=tanushreetumane@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).