Johannes Schindelin [off-list ref] writes:
Just another reason to hate CVS. Because it trained people to do that. If
it was not for the training by CVS, I would have strongly opposed to the
introduction of the "-m" switch to commit. It _encourages_ bad commit
messages.
Well, this really depends on the use-case, size of commit, ...
I often use a version control system for very low importance stuff. I
don't want to type a 3-lines long message to describe a 2-lines long
change in my ~/.emacs.el for example. I also work with people using
(sorry) svn to work collaboratively, but they don't even provide a log
message: the version control system here is just a replacement for
unison/NFS/whatever other way to have people edit files from different
machines.
For sure, in a context where code quality and review is important,
-m "xxx" isn't the way (except if you prefer your shell's line editor
to your actual editor).
--
Matthieu
This flag is actually useless since it is the default behavior, and
was mentionned in the SYNOPSYS, but not actually documented. Better
just deprecate it.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/git-commit.txt | 4 ++--
git-commit.sh | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..4324ca0 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--] [[-i] <files>...]
DESCRIPTION
-----------
@@ -91,7 +91,7 @@ OPTIONS
Used to amend the tip of the current branch. Prepare the tree
object you would want to replace the latest commit as usual
- (this includes the usual -i/-o and explicit paths), and the
+ (this includes the usual -i and explicit paths), and the
commit log editor is seeded with the commit message from the
tip of the current branch. The commit you create replaces the
current tip -- if it was a merge, it will have the parents of
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..3913097 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
-USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
@@ -138,6 +138,8 @@ do
shift
;;
-o|--o|--on|--onl|--only)
+ echo >&2 "Warning: --only option is now the default."
+ echo >&2 "It will be removed in a future version of git."
only=t
shift
;;
--
1.5.1.1
Hi,
On Mon, 7 May 2007, Matthieu Moy wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Just another reason to hate CVS. Because it trained people to do that. If
it was not for the training by CVS, I would have strongly opposed to the
introduction of the "-m" switch to commit. It _encourages_ bad commit
messages.
Well, this really depends on the use-case, size of commit, ...
Okay, so I use "-m" myself sometimes.
I often use a version control system for very low importance stuff. I
don't want to type a 3-lines long message to describe a 2-lines long
change in my ~/.emacs.el for example.
IIRC our record is 90+ lines of commit message for a one-line change.
I also work with people using (sorry) svn to work collaboratively, but
they don't even provide a log message: the version control system here
is just a replacement for unison/NFS/whatever other way to have people
edit files from different machines.
I positively _hate_ empty commit messages. There is _always_ something to
be said about the intent of the change, that has no place in the code.
For sure, in a context where code quality and review is important, -m
"xxx" isn't the way (except if you prefer your shell's line editor to
your actual editor).
I also find it very useful for my own pleasure when reviewing some logs. I
track config files, small scripts, documents, etc. with Git, and I found
myself looking for something in _all_ of them. The commit messages helped.
Commit messages, BTW, are somewhat of an artform. You cannot imagine how
slow I am writing them, because they should be helpful not only for the
reviewer, but also for the casual git-blame user, who wants to find out
the rationale of a change.
Ciao,
Dscho
Hi,
On Mon, May 07, 2007 at 01:05:44PM CEST, Johannes Schindelin wrote:
On Mon, 7 May 2007, Matthieu Moy wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
Just another reason to hate CVS. Because it trained people to do that. If
it was not for the training by CVS, I would have strongly opposed to the
introduction of the "-m" switch to commit. It _encourages_ bad commit
messages.
Well, this really depends on the use-case, size of commit, ...
Okay, so I use "-m" myself sometimes.
I'm maybe somewhat standing out of the crowd, but I sometimes use -m
for *very* long commit messages - just using separate -m parameters for
paragraphs and writing on; I tend to find it much more natural than
spawning an editor. Only when I find later that I've made an ugly typo
in the middle of 250-characters commandline or I figure out that I
should add some figure to the message, I throw in -e at the end and add
the final touches.
..snip..
Commit messages, BTW, are somewhat of an artform. You cannot imagine how
slow I am writing them, because they should be helpful not only for the
reviewer, but also for the casual git-blame user, who wants to find out
the rationale of a change.
But I agree that commit messages are somewhat of an artform, and
just finding a good headline can be quite difficult sometime. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett