login
Search
git-commit(1) doesn't allow you to make a commit without a commit message. This is annoying and doesn't properly preserve history in applications like snerp-vortex which replay a SVN dump into Git. You have to add `$msg = "Git made me do it" unless length $msg' somewhere. Is there really no way to add a commit with no message with the git tools? Will anything break if I manually construct a commit with no message? Are commit messages inherently part of the format or does git-commit(1) just think it knows better than me? --
On Sat, Apr 3, 2010 at 6:06 PM, Ævar Arnfjörð Bjarmason git-commit isn't really meant to be used by scripts. Try using git-commit-tree instead, which doesn't enforce a commit message. (Or use git fast-import; a quick glance at Snerp suggests that it's intended to be *fast*; using fast-import ought to make things vastly quicker.) Avery --
On Sun, Apr 4, 2010 at 1:15 PM, Ævar Arnfjörð Bjarmason Arg! You are right, sorry for the noise. I should not write emails during the night... I then suppose your only option is to use plumbing commands (see git(1)), in this case git-commit-tree. In general if you write scripts around git you should use only plumbing commands as they don't change the behavior. HTH, Santi --
Change git-commit(1) to accept a --allow-empty-message option analogous to the existing --allow-empty option which allows empty trees. This is mainly for compatability with foreign SCM systems. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- Documentation/git-commit.txt | 12 +++++++-- builtin/commit.c | 7 +++-- t/t7510-commit-allow-empty-message.sh | 41 +++++++++++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 6 deletions(-) create mode 100755 t/t7510-commit-allow-empty-message.sh diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 64fb458..2c1c2e1 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -10,9 +10,9 @@ SYNOPSIS [verse] 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author] - [--allow-empty] [--no-verify] [-e] [--author=<author>] - [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--] - [[-i | -o ]<file>...] + [--allow-empty] [--allow-empty-message] [--no-verify] [-e] + [--author=<author>] [--date=<date>] [--cleanup=<mode>] + [--status | --no-status] [--] [[-i | -o ]<file>...] DESCRIPTION ----------- @@ -131,6 +131,12 @@ OPTIONS from making such a commit. This option bypasses the safety, and is primarily for use by foreign scm interface scripts. +--allow-empty-message:: + Like --allow-empty this command is primarily for use by foreign + scm interface scripts. It allows you to create a commit with an + empty commit message without using plumbing commands like + linkgit:git-commit-tree[1]. + --cleanup=<mode>:: This option sets how the commit message is cleaned up. The '<mode>' can be one of 'verbatim', 'whitespace', 'strip', diff --git a/builtin/commit.c b/builtin/commit.c index c5ab683..7fd963e 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -65,8 +65,8 @@ static const char *template_file; ...
It's hard enough to get co-workers to write good commit messages. I wouldn't want to encourage them to skip writing them altogether (by the existence of this feature). Is there any reason why the git commit-tree plumbing didn't suffice? (in other words, "sure we can", but I'm asking, "are you sure we should?") Just my $.02. -- David --
In retrospect I probably should have sent a [PATCH RFC], this is
obviously somewhat of a delicate subject.
It's not so much about supporting scripting as exporting the
capabilities of the porcelain to the frontend utilities without
artificial limitations.
I encountered this limitation most recently while using hacking
snerp-vortex which uses git-commit(1) directly. While it should
ideally use git-commit-tree(1) or git-fast-import(1) it was easier at
the time to do:
message ||= "Git made me";
I thought it was silly that I had to either do that to fix an
otherwise working piece of software or rewrite how it does commits,
I'm a big fan of good commit messages, that's another reason why I
think this feature is a good idea.
I've read too many commit messages from people who're obviously
determined not to write any, but are being forced to do so by their
tools. Favorites include "more updates", "some changes", "..." (the
list goes on). I'd rather get nothing at all from those people than
more meaningless drivel. It would increase the signal-to-noise ratio
of git-log(1) output.
--
As a Porcelain, "git commit" has some leeway to enforce sensible policy on the users, and "forbid commit that does not explain anything" is one such policy. It is not generally a good idea to expose the full capabilities of plumbing to Porcelain if it leads to bad user behaviour, and such "artificial" limitations are safety features we do not want to remove. --
Heya,
You contradict yourself:
commit 5241b6bfe2285a6da598a0348c37b77964035bc8
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Dec 3 00:03:10 2007 -0800
git-commit --allow-empty
It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story. We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.
This is primarily for use by foreign scm interface scripts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--
Cheers,
Sverre Rabbelier
--
I personally don't mind very much removing --allow-empty, though. --
Heya, Ah, hmm. I vaguely remember some discussion in the past about empty commits, but I'm not sure what the conclusion there was? I think it was something like "if you want to create a marker, use tags instead, there's really no reason to be using --allow-empty". Wasn't there some use case for "--allow-emtpy" when creating an unrooted branch with an empty starting point, or somesuch? -- Cheers, Sverre Rabbelier --
Isn't the requirement of using a longish option like "--allow-empty-message" enough of a warning to users though? Although it seems reasonable for git _discourage_ bad practices, I think that should generally also be moderated with "... but if you _reallllly_ want to, you can do this somewhat annoying thing....". Forcing someone to use commit-tree, though, seems a bit much to me; an annoyingly long option seems about right. -Miles -- Love is the difficult realization that something other than oneself is real. [Iris Murdoch] --
Yes, but re-read the part you omitted from your quote, where Ævar makes it sound as if exposing plumbing's flexibility to the Porcelain layer is unconditionally a good thing. My point is it never is. And as you said (and as Sverre alluded to with his --allow-empty), longish option is one way to ensure that we do not unconditionally expose flexibility from the plumbing without thinking. --
Yes and no. There are other reasons not to use "git commit" in your import script. You probably want to pass --allow-empty, too, and --no-verify. And you probably want to use --cleanup=none to keep messages intact. But most of all, even if you do everything right, we still don't promise not to change it out from under you in a future version. Because it's porcelain, and the plumbing method is to use commit-tree. If commit-tree is too hard to use, I would rather see the plumbing made more friendly than encouraging people to build on top of porcelain. All of that being said, I looked at the snerp-vortex source code (which started this thread): http://github.com/rcaputo/snerp-vortex/blob/master/lib/SVN/Dump/Replayer/Git.pm It uses several pieces of porcelain. Some in silly ways, like calling "git status" to avoid calling git-commit when there are no changes and getting an error code. Which is silly (if you are importing, you probably want --allow-empty), wasteful (you just need the diff-index part of status), and now broken (because status is no longer "commit --dry-run", it always exits with status 0 whether there are changes or not). Then there are things like calling "git add -f" with arguments, and a "TODO: split arguments to handle larger filesets" comment. When he should be using update-index, which takes updates on stdin. He also notes in the README that it takes 250 seconds to convert his test repo to git, but only 70 to make a flat filesystem, and that he wants to move to using fast-import. So yes, it sucks that his importer does not support empty comments, and that the OP had to hack around it. But it already doesn't support many things (like commits with a large number of files, and from what I can see, files with spaces will break his `find` invocation). The right answer is for him to move to fast-import, which will be way faster, more robust, and is actually a supported plumbing interface. I don't think it's worth adding new features to support a ...
Thanks for looking at the importer, that'll be very useful when fixing it. But FWIW that `find` invocation isn't a bug. Perl doesn't have a " " input field separator so "my @files = `find . -type f`" does the I'm sorry that I brought snerp-vortex into this at all. It wasn't the main motivation behind this patch, just the straw that broke the camel's back. I've run into this limitation a lot when playing with and learning Git. Sometimes I'm e.g. making small throwaway repositories in /tmp using the porcelain for experimentation. Those have seen a lot of "blah!" commit messages immediately following "Git exited abnormally with code 1". Miles Bader said it better than I could. Tools should provide sane defaults and discourage bad practices, but they shouldn't *enforce* good practices. That'll inevitably burn people whose use for the tools isn't what you expect. Even if they Git maintainers don't like this people *do* write automated scripts and wrappers around Git using the porcelain, simply because that's what they're used to. Learning to use and switching to something like git-fast-import(1) or git-commit-tree(1) is too big of a hurdle for small throwaway scripts that take ~1m to write and aren't big dedicated importers like snerp-vortex. There's probably a lot of code out there doing `git commit -m"Yet another revision"' from some cron job. I sprinkled a lot of such meaningless messages about when I switched from Subversion (which supports empty commits in the porcelain) for these automated jobs to Git. Of course Junio may disagree (and that's fine!), how much you babysit your users is ultimately a design decision up to the maintainer. I just find this inconsistent with the rest of the porcelain which usually gives me plenty of ammo to blow both my legs of (and the planet they were standing on) if I so choose :) --
Hi, FWIW, I have no strong opinion about whether to add this --allow-empty-message option. Maybe it would make something more convenient for someone, though that has to be weighed against it making it harder for everyone else to read the manual. Instead, I just wanted to suggest that it is really worth the time to learn to use ‘git commit-tree’. Mostly because it does not take much time to learn at all. Hint: parent=HEAD && : or whatever && tree=$(git write-tree) && printf "%s\n" message | commit=$(git commit-tree "$tree" -p "$parent") && git update-ref refs/heads/somebranch "$commit" It is a very flexible tool, and I think you will find yourself fighting with git much less if you use tools like it in situations that would be unusual for a human to run into. Cheers, Jonathan --
I rearranged this example the last minute and broke it. You might say this proves the opposite of my point, though I don’t think that would be warranted. Anyway, to feed the message into ‘git commit-tree’ standard input, the relevant part of the example should have read as follows: commit=$( printf "%s\n" message | git commit-tree "$tree" -p "$parent" ) Incidentally, outside of the user manual and contrib/examples/ in the sources, the git documentation does not have many examples like this to point to, which is too bad. Sorry for the confusion, Jonathan --
I meant to mention this in my other response: I would prefer if such an
option doesn't clutter up the usage message. --allow-empty is already
there, and probably doesn't need to be. "git commit -h 2>&1 | wc -l"
shows a whopping 39 lines, which IMHO is too many for a short usage
summary. I mean, "--no-post-rewrite", is that really one of the top-used
In addition to the bug you mention later, you also probably want to do:
parent=`git rev-parse --verify HEAD`
[...]
git update-ref \
-m 'automated commit by tool X' \
refs/heads/somebranch $commit $parent
which will give your reflog entry a more useful message, and will
protect against simultaneous updates losing history (update-ref will
make sure, while locked, that somebranch contains the $parent sha1 you
wrote as part of the commit object).
And of course it still doesn't handle parentless root commits.
So doing it right really is a bit more work than just calling "git
commit".
-Peff
--
Change git-commit(1) to accept a --allow-empty-message option analogous to the existing --allow-empty option which allows empty trees. This is mainly for compatability with foreign SCM systems. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- Documentation/git-commit.txt | 6 +++++ builtin/commit.c | 7 +++-- t/t7510-commit-allow-empty-message.sh | 41 +++++++++++++++++++++++++++++++++ 3 files changed, 51 insertions(+), 3 deletions(-) create mode 100755 t/t7510-commit-allow-empty-message.sh diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 64fb458..aa18bee 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -131,6 +131,12 @@ OPTIONS from making such a commit. This option bypasses the safety, and is primarily for use by foreign scm interface scripts. +--allow-empty-message:: + Like --allow-empty this command is primarily for use by foreign + scm interface scripts. It allows you to create a commit with an + empty commit message without using plumbing commands like + linkgit:git-commit-tree[1]. + --cleanup=<mode>:: This option sets how the commit message is cleaned up. The '<mode>' can be one of 'verbatim', 'whitespace', 'strip', diff --git a/builtin/commit.c b/builtin/commit.c index c5ab683..7fd963e 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -65,8 +65,8 @@ static const char *template_file; static char *edit_message, *use_message; static char *author_name, *author_email, *author_date; static int all, edit_flag, also, interactive, only, amend, signoff; -static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship; -static int no_post_rewrite; +static int quiet, verbose, no_verify, allow_empty, allow_empty_message, dry_run; +static int no_post_rewrite, renew_authorship; static char *untracked_files_arg, *force_date; /* * The default commit message cleanup mode will remove the lines @@ ...
Ditto. You are falling into the same trap as everybody else does when showing off your shiny new toy. A missing but very necessary test is that "commit" with your patch does still fail when an empty message is given without the new option. It takes a conscious effort to carefully make sure that your shiny new toy does not trigger when it shouldn't, especially when you are so excited by seeing it work when it should. But that is part of the art of writing good test scripts. t/t7500-commit.sh | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh index 9f5c3ed..aa9c577 100755 --- a/t/t7500-commit.sh +++ b/t/t7500-commit.sh @@ -193,4 +193,26 @@ test_expect_success 'commit -F overrides -t' ' commit_msg_is "-F log" ' +test_expect_success 'Commit without message is allowed with --allow-empty-message' ' + echo "more content" >>foo && + git add foo && + >empty && + git commit --allow-empty-message <empty && + commit_msg_is "" +' + +test_expect_success 'Commit without message is no-no without --allow-empty-message' ' + echo "more content" >>foo && + git add foo && + >empty && + test_must_fail git commit <empty +' + +test_expect_success 'Commit a message with --allow-empty-message' ' + echo "even more content" >>foo && + git add foo && + git commit --allow-empty-message -m"hello there" && + commit_msg_is "hello there" +' + test_done --
Thanks for shepherding the patch and committing it, and for pointing out what I could have done better. I'll try not to make similar mistakes with future submissions. --
I just put it there because --allow-empty was there and I thought the SYNOPSIS might be going for a complete listing. I completely agree though, the option shouldn't be in the SYNOPSIS, and neither should --allow-empty be. They're both analogous to obscure options like --porcelain (which isn't listed). I've just submitted a new patch to rectify this. I can send another one to remove --allow-empty from the SYNOPSIS. --
The --allow-empty option is too rarley used to warrant being displayed
in the SYNOPSIS. It should only be mentioned in the main body of the
documentation like --porcelain.
The issue was raised in the thread discussing the new
--allow-empty-message option (see 1aadbfad) by Jeff King
<peff@peff.net>:
http://marc.info/?l=git&m=127054334121604
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Documentation/git-commit.txt | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64fb458..ed2cd95 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -10,9 +10,8 @@ SYNOPSIS
[verse]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
- [--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
- [[-i | -o ]<file>...]
+ [--no-verify] [-e] [--author=<author>] [--date=<date>]
+ [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
--
1.7.0.4.298.gc81d
--
Heya, The hash of that commit is likely to change before it is included, so I'm not sure if it's wise to include it here right now, unless Junio is willing to make sure this reference stays correct? -- Cheers, Sverre Rabbelier --
The --allow-empty option is too rarley used to warrant being displayed
in the SYNOPSIS. It should only be mentioned in the main body of the
documentation like --porcelain.
The issue was raised in the thread discussing the new
--allow-empty-message option by Jeff King <peff@peff.net>:
http://marc.info/?l=git&m=127039258902941
http://marc.info/?l=git&m=127054334121604
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
I'd forgotten how the Git project likes rebasing :)
Here's a better patch that just cites the two relevant mailing list
posts instead of the commit sha1.
Documentation/git-commit.txt | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64fb458..ed2cd95 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -10,9 +10,8 @@ SYNOPSIS
[verse]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
- [--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
- [[-i | -o ]<file>...]
+ [--no-verify] [-e] [--author=<author>] [--date=<date>]
+ [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
--
1.7.0.4.298.gc81d
--
Heya, It's not so much the rebasing, but your patch gets applied manually from the mbox (meaning a different timestamp) by Junio (meaning a different committer), who adds his S-o-b (meaning a different commit message), so yeah, the hash is gonna change ;). -- Cheers, Sverre Rabbelier --
Of course, but in this case the patch had already been pushed by Junio to the Git repository as 1aadbf, my original commit was 1eb6f8. The SHA1 wouldn't change when it was cherry-picked to master unless it was further rewritten. But in any case referencing the mailing list post instead of the SHA1 is better. --
Hi, On Thu, Apr 8, 2010 at 1:28 AM, Ævar Arnfjörð Bjarmason s/rarley/rarely/ -- Cheers, Ray Chuan --
The --allow-empty option is too rarely used to warrant being displayed
in the SYNOPSIS. It should only be mentioned in the main body of the
documentation like --porcelain.
The issue was raised in the thread discussing the new
--allow-empty-message option by Jeff King <peff@peff.net>:
http://marc.info/?l=git&m=127039258902941
http://marc.info/?l=git&m=127054334121604
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Thanks for catching that. Here's the commit without the tyop :)
Documentation/git-commit.txt | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64fb458..ed2cd95 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -10,9 +10,8 @@ SYNOPSIS
[verse]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
- [--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
- [[-i | -o ]<file>...]
+ [--no-verify] [-e] [--author=<author>] [--date=<date>]
+ [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
--
1.7.0.4.298.gc81d
--
IMO the option should not be removed from the synopsis section of the documentation. I would agree that it is removed from the output of 'git commit -h', and I think this was the original intent when someone (Junio?) suggested to remove it. -- Hannes --
Please don't cite marc, especially when you refer to a thread or a patch.
Their interface, even in the "raw" mode, does not give the message headers
(presumably by design, in order to block e-mail address harvesters) that
makes it unusable to get patches out of for applying.
Giving a message-ID would be vendor neutral and a useful alternative
instead, like so:
Message-ID: <20100406055530.GE3901@coredump.intra.peff.net>
Then people can paste it after "http://mid.gmane.org/" or feed it to their
I do not think Jeff was against having a complete listing in the
documentation. Wasn't his suggestion about "git commit -h" output?
--
The --allow-empty option is too rarely used to warrant being displayed in the SYNOPSIS. It should only be mentioned in the main body of the documentation like --porcelain. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Sorry, I'm new here and there was no mention of this in Documentation/SubmittingPatches. I looked through `git log' for the project and found 10 such links in other commit messages. Now that I look closer there are 14 references to some `Message-ID:', but of course someone getting it wrong in the past doesn't mean that it's a good idea to follow their example. I won't cite marc.info Yes I misread (or rather, mis-recalled) the content of his message. He was indeed talking about `git commit -h' output, but I subsequently updated my --allow-empty-message patch to omit it from the SYNOPSIS for git-commit(1). I've removed the links to `marc.info' (or any Message-ID's) since they aren't pertinent anymore. The relatively obscure --allow-empty* options should regardless of that misunderstanding probably be omitted from the SYNOPSIS section. It would reduce the cognitive load of the casual manual reader who's trying to get an idea of the most common usage for the command. As for Jeff's suggestion of omitting options from the `--help' output: I couldn't find a way to do that using parse-options.[ch]. It's also customary for `--help' to include the full usage examples regardless of how long they get (just look at wget, ls etc.). The SYNOPSIS sections in manual pages by comparison usually aim for brevity. Documentation/git-commit.txt | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 64fb458..ed2cd95 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -10,9 +10,8 @@ SYNOPSIS [verse] 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] ...
On Wed, Apr 7, 2010 at 12:28 PM, Ævar Arnfjörð Bjarmason You can hide options from the -h output (not --help-all) by using the PARSE_OPT_HIDDEN flag. --
I'll amend the earlier "allow-empty-message" one from you to cover this topic. -- >8 -- From: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Tue, 6 Apr 2010 08:40:35 +0000 Subject: [PATCH] Add option to git-commit to allow empty log messages Change git-commit(1) to accept the --allow-empty-message option to allow a commit with an empty message. This is analogous to the existing --allow-empty option which allows a commit that records no changes. As these are mainly for interoperating with foreign SCM systems, and are not meant for normal use, ensure that "git commit -h" does not talk about them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Documentation/git-commit.txt | 8 +++++++- builtin/commit.c | 12 +++++++++--- t/t7500-commit.sh | 22 ++++++++++++++++++++++ 3 files changed, 38 insertions(+), 4 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 64fb458..32c482f 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author] - [--allow-empty] [--no-verify] [-e] [--author=<author>] + [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...] @@ -131,6 +131,12 @@ OPTIONS from making such a commit. This option bypasses the safety, and is primarily for use by foreign scm interface scripts. +--allow-empty-message:: + Like --allow-empty this command is primarily for use by foreign + scm interface scripts. It allows you to create a commit with an + empty commit message without using plumbing commands like + linkgit:git-commit-tree[1]. + --cleanup=<mode>:: This option sets how ...
My suggestion was for "git commit -h", and your amended patch addresses it. Thanks. For the record, I am _also_ against having a complete listing at the header of the documentation, but last time this was discussed some others felt differently, and I don't think we reached a consensus on what the manpages should look like (right now some have a very terse synopsis, and some try to list every option). -Peff --
He calls `find $dir -type f`, without a quotemeta on $dir, which perl will pass to the shell to interpret (and is actually a security issue if I can convince you to try importing my svn repository with directory '; I don't in particular have a problem with --allow-empty-message for casual use. Why anybody would want to use it when they could type the much shorter -mnone, I don't know. But it is long enough that people will have to think about using it, which means the people who do so will probably really want it. -Peff --
