Is it possible to make "git commit --allow-empty" as a default configuration

[chucklu]

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.19.0.windows.1
cpu: x86_64
built from commit: d96bb8bc6c636a8869140e860e72e7bdf64bd790
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.16299.665]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Rebase: Enabled
Enable Builtin Stash: Enabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

 git cherry-pick 7661d4^..master --strategy=recursive -X ours

• What did you expect to occur after running these commands?

cherry-pick successfully

• What actually happened instead?

pop-up lots of message caused by merge commit, The problem is here, I hope I can configure the "git commit --allow-empty" as a global default configuration to skip the verify process.

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

If you wish to skip this commit, use:

    git reset

Then "git cherry-pick --continue" will resume cherry-picking
the remaining commits.

[PhilipOakley]

@chucklu This (discussion) is probably more suitable for the upstream git list git@vger.kernel.org as it is probably unreasonable to have an symmetry between upstream Linux and the Git-for Windows.

The git@vger.kernel.org list is plain text only (any HTML is treated as spam), and it has a number of archives including https://public-inbox.org/git/?q= which can be searched to see if this has come up before.

[dscho]

@chucklu or you dive in and patch Git. To do so

• install the Git for Windows SDK,
• sdk cd git
• follow aaab842 as an example to add commit.allowEmpty
• commit, following the same aaab842 as example
• push to a fork
• open a PR
• happiness all around!

[tanushree27]

@dscho pull request for this #1902.

[dscho]

@dscho pull request for this #1902.

Nice! Please make sure to include a sentence like this in the commit message, to auto-close this here ticket once the PR gets merged:

This closes https://github.com/git-for-windows/git/issues/1854

[dscho]

@chucklu people are questioning your motives. It would be really a good time to speak up and describe why you need this. People worked to fulfill your wishes, and the least you can do now is to be quite a bit more chatty than you have been. Describe your use case thoroughly, please.

[chucklu]

@dscho Sorry , I don't understand. What did you mean by "people are questioning your motives"? I did not receive any notifications about that. I receive the notification of activity in this issue, but nobody ask me questions except you.

Anyway, my user case is like this :
When I want to cherr-pick commits from A to G (ABCDEFG), imagine C and E are merge commits.
Then I will get lots of popup like:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

If you wish to skip this commit, use:

git reset

Then "git cherry-pick --continue" will resume cherry-picking
the remaining commits.

[dscho]

What did you mean by "people are questioning your motives"

You did not follow how much work @tanushree27 did for you? That's not good.

See here: #1902 and here: https://public-inbox.org/git/20181103112535.5730-1-tanushreetumane@gmail.com/#r, and in particular here: https://public-inbox.org/git/87d0rm7zeo.fsf@evledraar.gmail.com/ and here: https://public-inbox.org/git/87zhuc1xcx.fsf@evledraar.gmail.com/ and here: https://public-inbox.org/git/xmqqzhucpa37.fsf@gitster-ct.c.googlers.com/

From the mails:

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 37f7a85 ("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.

and

[...] the whole "why would anyone want this?" explanation is still missing, and this still smells like a workaround for a bug we should be fixing elsewhere in the sequencing code.

and from the Git maintainer himself:

I share the same impression that this is sweeping a bug under a wrong rug.

So you see, other people have been busy on your behalf. It is time that this became a bit more balanced, and you put a little bit of effort to your own ends, too.

[...] my user case is like this: When I want to cherr-pick commits from A to G (ABCDEFG), image C and E are merge commits. [... warning about empty commits...]

That does not look to me as if you wanted to end up with empty commits. Instead, they should be skipped. That is what you would do manually, if you follow the instructions, and if you encounter this situation frequently, I can see how you want a config setting (and/or cherry-pick option) to skip commits silently that would become empty (as that is an indication that the changes had already been applied in the current HEAD).

[chucklu]

@dscho I apologize that I have no idea about the conversation happened between you and git@vger.kernel.org.
I did not subscribe the git@vger.kernel.org, maybe you can send me a copy if next time you talk about the related issue submit by me.
Thanks for all your contribution.

Is there anything else I can do for you?

[dscho]

I apologize that I have no idea about the conversation happened between you and git@vger.kernel.org.

You also seem to have been oblivious to #1902. If I were that contributor, I would think three times before implementing a feature you wished for, next time. Not even a "thank you". Not even that.

Is there anything else I can do for you?

You doing something for me? Seriously? The entire time other people are doing something for you. And the least you could do would be to answer this:

[...] my user case is like this: When I want to cherr-pick commits from A to G (ABCDEFG), image C and E are merge commits. [... warning about empty commits...]

That does not look to me as if you wanted to end up with empty commits. Instead, they should be skipped. That is what you would do manually, if you follow the instructions, and if you encounter this situation frequently, I can see how you want a config setting (and/or cherry-pick option) to skip commits silently that would become empty (as that is an indication that the changes had already been applied in the current HEAD).

[michaelblyons]

@dscho Whoa there. The mailing list thread was never linked from this thread or from pull request #1902 until @chucklu expressed confusion when you suddenly accused him of bad motives.

Chuck has now written about his use case and (I hope) can be forgiven for not understanding that your response to it contained a question. I, too, did not notice that there is an implied request for clarification on whether commits should be skipped or added as empty, since there was not a direct question.

I am sure that being a maintainer is a tough job, and I see a lot of bad bug reports in this repo (and try to help identify the duplicates myself). This time, though, I think you are not being fair. He said "thank you" in the post immediately before you complained about lack of gratitude.

[dscho]

He said "thank you" in the post immediately before you complained about lack of gratitude.

I am not to be thanked, Tanushree is. And in the PR they opened. And help with the review would have been appreciated, too.

This has nothing to do with maintaining being a tough job. This has all to do with seeing one user asking for a feature, another person addressing that wish, and that latter person not being acknowledged.

I think that @tanushree27 did a fantastic job, and I am just sad to see that this is so one-sided. I want Git for Windows to be a fun place for contributors. And this here ticket is no fun, despite a couple of people putting in a real effort. So I feel the behavior by @chucklu quite discouraging, which is sad, because they are relatively active a bug reporter. But the communication cannot be starved from one side if it wants to work.

[chucklu]

@dscho I just read the popup again

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

If you wish to skip this commit, use:

git reset

Then "git cherry-pick --continue" will resume cherry-picking
the remaining commits.

I found what I want is the second option(git reset) to skip the duplicate commit instead of allow empty.
It seems the first time I submit the issue with wrong description, sorry for that.
Actually, most time I am using the TortoiseGit the do the cherry-pick, that's why I mistaken the option1 and option2.

[dscho]

I found what I want is the second option(git reset) to skip the duplicate commit instead of allow empty.

I guess it's case closed now?