RE: Is this a bug?
Hi, I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef " ' Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message. Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? Thanks! David Wade Analyst, Seismic Imaging Development ITC SUB RES Statoil ASA Mobile: +47 97572157 Email: da...@statoil.com Visitor address: Vassbotnen 23, Forus, Norway Incorporation number: NO 923 609 016 MVA www.statoil.com Please consider the environment before printing this e-mail. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this a bug?
On 02/19/2013 10:32 AM, David Wade wrote: > Hi, > > I wrote a commit message beginning with a hash (#) character, like > this: 'git commit -m "#ifdef " ' > > Everything went okay when committing, but then I tried 'git commit > -amend' and without editing the commit message I was told I had an > empty commit message. > > Is this a problem with my text editor (vim 7.2) or git itself? (git > version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do > ;-) ? > Lines starting with a hash sign are considered comments by git commit. If you fire it up without '-m' you'll see that git puts all its own notes about the commit in commented-out lines. While empty commit messages aren't really unacceptable by git's model, they're considered "almost certainly user errors". I expect the -m flag being present when running 'git commit' causes the check for empty message to be skipped, which isn't the case when amending the commit. Btw, when I write messages probably similar to the one you just did, I tend to write: Use compat-layer __builtin_clz() #ifndef __GNUC__ precisely to avoid this issue. It also puts the imperative first, which I find makes for smoother reading. Putting the condition first screams for a comma and a slight stagger in reading flow, like so: Unless built with gcc, use compat-layer __builtin_clz() -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this a bug?
On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote: > Hi, > > I wrote a commit message beginning with a hash (#) character, like this: 'git > commit -m "#ifdef " ' > > Everything went okay when committing, but then I tried 'git commit -amend' > and without editing the commit message I was told I had an empty commit > message. > > Is this a problem with my text editor (vim 7.2) or git itself? (git version > 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? The problem is that when doing interactive editing of messages (like 'git commit --amend' does), git considers '#' as a comment-character. You can disable this by using the --cleanup=verbatim switch (or some other suiting cleanup-setting, see 'git help commit'). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this a bug?
On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund wrote: > On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote: >> Hi, >> >> I wrote a commit message beginning with a hash (#) character, like this: >> 'git commit -m "#ifdef " ' >> >> Everything went okay when committing, but then I tried 'git commit -amend' >> and without editing the commit message I was told I had an empty commit >> message. >> >> Is this a problem with my text editor (vim 7.2) or git itself? (git version >> 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? > > The problem is that when doing interactive editing of messages (like > 'git commit --amend' does), git considers '#' as a comment-character. > You can disable this by using the --cleanup=verbatim switch (or some > other suiting cleanup-setting, see 'git help commit'). Nobody is always conscious about the leading # in commit message to do that. I once edited a commit message and the auto-wrap feature put '#' at the beginning of the line. I saved and went on without noticing one line was lost until much later :( Perhaps we should change the comment signature a bit to reduce accidents, like only recognize '#' lines as comments after a special line like # this is not a comment ### START OF COMMENT ### # this is a comment -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this a bug?
On Tue, Feb 19, 2013 at 6:02 AM, Duy Nguyen wrote: > On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund wrote: >> On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote: >>> Hi, >>> >>> I wrote a commit message beginning with a hash (#) character, like this: >>> 'git commit -m "#ifdef " ' >>> >>> Everything went okay when committing, but then I tried 'git commit -amend' >>> and without editing the commit message I was told I had an empty commit >>> message. >>> >>> Is this a problem with my text editor (vim 7.2) or git itself? (git version >>> 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? >> >> The problem is that when doing interactive editing of messages (like >> 'git commit --amend' does), git considers '#' as a comment-character. >> You can disable this by using the --cleanup=verbatim switch (or some >> other suiting cleanup-setting, see 'git help commit'). > > Nobody is always conscious about the leading # in commit message to do > that. I once edited a commit message and the auto-wrap feature put '#' > at the beginning of the line. I saved and went on without noticing one > line was lost until much later :( Perhaps we should change the comment > signature a bit to reduce accidents, like only recognize '#' lines as > comments after a special line like > > # this is not a comment > ### START OF COMMENT ### > # this is a comment Or maybe --amend should imply --cleanup=whitespace. -- Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this a bug?
Phil Hord writes: > Or maybe --amend should imply --cleanup=whitespace. I am fairly negative on that. Such a hidden linkage, even if it is documented, is just one more thing people need to learn. It _might_ be interesting (note: I did not say "worthwhile" here) to think what happens if we scanned the message (either coming from the commit being amended, -F file option, or -m message option), picked a punctuation character that does not appear at the beginning of the lines in it, and automatically adjusted core.commentchar if '#' appears at the beginning of one of the lines, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
is this a bug of git-diff?
The output of git-diff is different from my expectation. It may skip some lines of context. For the case of the diff result attached here, a blank line and a line with a leading slash is skipped. Please check out the attached files for details. Thanks. ab.patch Description: Binary data int a = 1; /* * 1 * 2 * 3 * added */ int a = 1; /* * 1 * 2 * 3 */
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 8:23 AM, eric liou wrote: > The output of git-diff is different from my expectation. > It may skip some lines of context. git-diff is using a default of 3 lines of context above and below the changes. In your example, there is only two lines of context below the change, so only two lines are displayed. Above the change, three lines are displayed, as expected. That's why the blank line and leading slash line are not displayed. You can change the number of context lines by invoking git-diff with -U. Hope that helps, Antoine -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:
> Thank you for the quick reply.
> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;"
Oh OK, I see.
Git tries to name the function where the changes take place. This is
purely informative.
In your example, you don't have any function so of course the
information is not very helpful.
Typically it will look like the following, helping the reader by
giving the function name:
@@ -591,6 +609,14 @@ int cmd_grep(int argc, const char **argv, const
char *prefix)
paths[1] = NULL;
}
+ if (!use_index) {
+ if (cached)
+ die("--cached cannot be used with --no-index.");
+ if (list.nr)
+ die("--no-index cannot be used with revs.");
+ return !grep_directory(&opt, paths);
+ }
+
if (!list.nr) {
if (!cached)
setup_work_tree();
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
Antoine Pelisse writes: > On Wed, May 15, 2013 at 8:52 AM, eric liou wrote: >> Thank you for the quick reply. >> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;" Antoine's answer is correct. In addition, I'd say that you may want to enable color in the output to make it clearer (the @@ ... @@ part would be colored, but not the function name): git config --global color.ui auto -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote: > Antoine's answer is correct. In addition, I'd say that you may want to > enable color in the output to make it clearer (the @@ ... @@ part would > be colored, but not the function name): > > git config --global color.ui auto I wonder if that should be the default. I've advised a lot of people to turn it on and it seems to me that a user is much more likely to go looking for a "turn color off" option than realise that color is an option at all. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this a bug of git-diff?
On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote: > On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote: > > Antoine's answer is correct. In addition, I'd say that you may want to > > enable color in the output to make it clearer (the @@ ... @@ part would > > be colored, but not the function name): > > > > git config --global color.ui auto > > I wonder if that should be the default. I've advised a lot of people to > turn it on and it seems to me that a user is much more likely to go > looking for a "turn color off" option than realise that color is an > option at all. +1. My settings have been there for so long that I thought it was the default. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Default for color.ui (was Re: is this a bug of git-diff?)
John Keeping writes: > I wonder if that should be the default. I've advised a lot of people to > turn it on and it seems to me that a user is much more likely to go > looking for a "turn color off" option than realise that color is an > option at all. I'd love to see this by default, yes. Maybe a 2.0 change? If people agree that this is a good change, would we need a transition plan? I'd say no, as there is no real backward incompatibility involved. People who dislike colors can already set color.ui=false, and seeing colors can hardly harm them, just temporarily reduce the comfort for them. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Default for color.ui (was Re: is this a bug of git-diff?)
On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy wrote: > John Keeping writes: > >> I wonder if that should be the default. I've advised a lot of people to >> turn it on and it seems to me that a user is much more likely to go >> looking for a "turn color off" option than realise that color is an >> option at all. > > I'd love to see this by default, yes. Maybe a 2.0 change? > > If people agree that this is a good change, would we need a transition > plan? I'd say no, as there is no real backward incompatibility involved. > People who dislike colors can already set color.ui=false, and seeing > colors can hardly harm them, just temporarily reduce the comfort for > them. I vote for this. It's the first thing I do in any setup, even the ones that are note mine. I've also seen it in basically all the tutorials, even before setting user.name/email. I also don't see the point of a transition plan. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
