Re: Log messages beginning # and git rebase -i
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Duy Nguyen pclo...@gmail.com writes: On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? $ GIT_EDITOR=touch git commit --cleanup=verbatim [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: # modified: foo.txt # # Changes not staged for commit : # modified: foo.txt # # Untracked files: # last-synchro.txt # 1 file changed, 1 insertion(+), 1 deletion(-) You really don't want that in day-to-day use. I do not quite follow this example. The user said I'll be responsible for cleaning up by giving the option. It is up to the user to use an editor that is something a bit more intelligent than touch to remove the instructional comments meant for humans after reading them. Yes, --cleanup=verbatim does what it says it does. Now, my claim is that it does not answer the use-case I want an easy way to talk about # in a commit message. First, you have to specify --cleanup=verbatim _before_ typing the message, hence before knowing that you may need a #. Then, as you say, it is up to the user to remove things that Git has added. Why would we ask the user to do this when we have a way to have the tool do it? 2) Modify Git to add scissors by default, and use --cleanup=scissors by default. I just did $ git commit --amend --cleanup=scissors (with and without --amend) and it seems to do exactly that ;-). Ah, I did my test in the same repo I messed-up with --cleanup=verbatim. It's better than I thought then. So a viable alternative to the backslas-escaping would be to change commit.cleanup to scissors by default. -- 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: Log messages beginning # and git rebase -i
Matthieu Moy matthieu@grenoble-inp.fr writes: Then, as you say, it is up to the user to remove things that Git has added. Why would we ask the user to do this when we have a way to have the tool do it? The timeline of development, perhaps? I thought cleanup=scissors was a fairly recent invention that hasn't been used widely yet. -- 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: Log messages beginning # and git rebase -i
Matthieu Moy matthieu@grenoble-inp.fr writes: Duy Nguyen pclo...@gmail.com writes: On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? $ GIT_EDITOR=touch git commit --cleanup=verbatim [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: # modified: foo.txt # # Changes not staged for commit : # modified: foo.txt # # Untracked files: # last-synchro.txt # 1 file changed, 1 insertion(+), 1 deletion(-) You really don't want that in day-to-day use. I do not quite follow this example. The user said I'll be responsible for cleaning up by giving the option. It is up to the user to use an editor that is something a bit more intelligent than touch to remove the instructional comments meant for humans after reading them. 2) Modify Git to add scissors by default, and use --cleanup=scissors by default. I just did $ git commit --amend --cleanup=scissors (with and without --amend) and it seems to do exactly that ;-). -- 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: Log messages beginning # and git rebase -i
Junio C Hamano gits...@pobox.com writes: OK. So the proposal on the table is that a backslash at the beginning of a line is stripped. Yes. Stripping part should look like this. Thanks. To make it work for things like git commit --amend, you would need to prefix any line that comes from the payload that begins with the core.commentchar or a backslash with a backslash. That's it, probably the hardest part. No Git time budget for now, but I'm adding this here in case I get time or a student to work on it: http://git.wiki.kernel.org/index.php/SmallProjectsIdeas -- 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: Log messages beginning # and git rebase -i
On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? $ GIT_EDITOR=touch git commit --cleanup=verbatim [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: # modified: foo.txt # # Changes not staged for commit : # modified: foo.txt # # Untracked files: # last-synchro.txt # 1 file changed, 1 insertion(+), 1 deletion(-) You really don't want that in day-to-day use. How about --cleanup=scissors? The chance that you have the same cut line in your commit message is really low, compared to having comment characters. -- 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: Log messages beginning # and git rebase -i
Thank you for looking into this. -- Ed Avis e...@waniasset.com -- 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: Log messages beginning # and git rebase -i
On Wed, Jul 29, 2015 at 7:17 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Duy Nguyen pclo...@gmail.com writes: On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? $ GIT_EDITOR=touch git commit --cleanup=verbatim [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: # modified: foo.txt # # Changes not staged for commit : # modified: foo.txt # # Untracked files: # last-synchro.txt # 1 file changed, 1 insertion(+), 1 deletion(-) You really don't want that in day-to-day use. How about --cleanup=scissors? I can read this in two different ways: 1) Keeping git as-is and suggest users to use --cleanup=scissors This has the same problem as --cleanup=verbatim: it doesn't work as-is since Git doesn't insert the scissors. You can hack around it by adding them by yourself when you need it, but it's really not convenient. You have to anticipate that you're going to require a # and call commit with --cleanup=scissors, add the scissors. And repeat it if you need to commit --amend. 2) Modify Git to add scissors by default, and use --cleanup=scissors by default. This is actually more or less what SVN does: it inserts a line --This line, and those below, will be ignored--, and the equivalent of what Git adds as comments in the template is inserted below this line. I don't think option 1) is good. The fact that we have the --cleanup= option shouldn't serve as an excuse to do nothing. I'd be fine with option 2), but I find it much more intrusive than to allow a simple backslash-escaping as I suggest. auto backslashing could cause some annoyance. Emacs supports rearranging a paragraph to fit in a fixed text column. This generated backslash may be moved around, no longer at the beginning of the line, and it will remain in the commit message. I don't know how popular this feature is outside emacs. Having said that, even scissors has its own (and probably bigger) problem: when you commit after conflict resolution, git inserts a Conflicts: paragraph, prepended by core.commentChar. With default settings, it serves as a reminder, but will be automatically stripped. With scissors, it stays by default because it's placed before the scissor line. -- 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: Log messages beginning # and git rebase -i
Duy Nguyen pclo...@gmail.com writes: On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? $ GIT_EDITOR=touch git commit --cleanup=verbatim [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: # modified: foo.txt # # Changes not staged for commit : # modified: foo.txt # # Untracked files: # last-synchro.txt # 1 file changed, 1 insertion(+), 1 deletion(-) You really don't want that in day-to-day use. How about --cleanup=scissors? I can read this in two different ways: 1) Keeping git as-is and suggest users to use --cleanup=scissors This has the same problem as --cleanup=verbatim: it doesn't work as-is since Git doesn't insert the scissors. You can hack around it by adding them by yourself when you need it, but it's really not convenient. You have to anticipate that you're going to require a # and call commit with --cleanup=scissors, add the scissors. And repeat it if you need to commit --amend. 2) Modify Git to add scissors by default, and use --cleanup=scissors by default. This is actually more or less what SVN does: it inserts a line --This line, and those below, will be ignored--, and the equivalent of what Git adds as comments in the template is inserted below this line. I don't think option 1) is good. The fact that we have the --cleanup= option shouldn't serve as an excuse to do nothing. I'd be fine with option 2), but I find it much more intrusive than to allow a simple backslash-escaping as I suggest. -- 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: Log messages beginning # and git rebase -i
Eric Sunshine sunshine at sunshineco.com writes: the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. I was thinking of the default configuration. But you are right, this applies to whatever the comment character is - so if commentChar is set to * for example, then log lines beginning with * should get an extra space prepended in git rebase --interactive so that they don't get lost. -- Ed Avis e...@waniasset.com -- 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: Log messages beginning # and git rebase -i
Ed Avis e...@waniasset.com writes: Eric Sunshine sunshine at sunshineco.com writes: the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. I was thinking of the default configuration. But you are right, this applies to whatever the comment character is - so if commentChar is set to * for example, then log lines beginning with * should get an extra space prepended in git rebase --interactive so that they don't get lost. Actually, is there any reason why we do not allow a simple escaping like \# this is a line starting with # \\ this is a line starting with \ # this is a comment ? -- 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: Log messages beginning # and git rebase -i
Matthieu Moy matthieu@grenoble-inp.fr writes: Ed Avis e...@waniasset.com writes: Eric Sunshine sunshine at sunshineco.com writes: the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. I was thinking of the default configuration. But you are right, this applies to whatever the comment character is - so if commentChar is set to * for example, then log lines beginning with * should get an extra space prepended in git rebase --interactive so that they don't get lost. Actually, is there any reason why we do not allow a simple escaping like \# this is a line starting with # \\ this is a line starting with \ # this is a comment What are we trying to achieve? Munging the original # I want this line intact to any other form like # I want this... is as bad as losing it. If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? -- 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: Log messages beginning # and git rebase -i
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Actually, is there any reason why we do not allow a simple escaping like \# this is a line starting with # \\ this is a line starting with \ # this is a comment What are we trying to achieve? What I would like would be a simple way to: 1) Allow any commit message to be typed. If I want to talk about #include in my commit message, I should have an easy way to do so. 2) Allow commands that pop an editor on an existing message to preserve the original message, whatever it is. Well, actually Git even strips # lines even if it doesn't pop the editor. Currently, I can for example: $ git commit -m #include -a [detached HEAD 0f36ec9] #include 1 file changed, 1 insertion(+), 1 deletion(-) $ GIT_EDITOR=touch git commit --amend Aborting commit due to empty commit message. A simple escaping scheme like the above can solve both points: 1) If I want to talk about #include in my commit message, I can spell it \#include and Git would remove the \. The same way, if I want to tell my shell about a inside a string, I can write double-quote:\. and get a litteral double-quote. 2) A command that pops an editor could add the escaping where needed, pop the editor, and then unescape. A command like pick in rebase -i could escape the message, and feed it to git commit which would unescape it. Munging the original # I want this line intact to any other form like # I want this... is as bad as losing it. It would modify it only when shown in the text editor. The object database would contain unescaped message, hence git log would show it unescaped for example. backslash-escaping special characters seems very natural to me, and I guess it would be for most computer-scientists. If I have problem with a special character, the first thing I would try would be to add a backslash in front of it. If the user wants whatever she types in the resulting commit literally, there is the --cleanup=choice option, no? $ GIT_EDITOR=touch git commit --cleanup=verbatim [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: # modified: foo.txt # # Changes not staged for commit : # modified: foo.txt # # Untracked files: # last-synchro.txt # 1 file changed, 1 insertion(+), 1 deletion(-) You really don't want that in day-to-day use. -- 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: Log messages beginning # and git rebase -i
Matthieu Moy matthieu@grenoble-inp.fr writes:
A simple escaping scheme like the above can solve both points:
1) If I want to talk about #include in my commit message, I can spell it
\#include and Git would remove the \. The same way, if I want to tell
my shell about a inside a string, I can write double-quote:\.
and get a litteral double-quote.
2) A command that pops an editor could add the escaping where needed,
pop the editor, and then unescape. A command like pick in rebase
-i could escape the message, and feed it to git commit which would
unescape it.
...
backslash-escaping special characters seems very natural to me,...
OK. So the proposal on the table is that a backslash at the
beginning of a line is stripped.
Stripping part should look like this. To make it work for things
like git commit --amend, you would need to prefix any line that
comes from the payload that begins with the core.commentchar or a
backslash with a backslash.
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index 1259ed7..39ecb92 100644
--- a/builtin/stripspace.c
+++ b/builtin/stripspace.c
@@ -52,6 +52,11 @@ void stripspace(struct strbuf *sb, int skip_comments)
}
newlen = cleanup(sb-buf + i, len);
+ if (newlen sb-buf[i] == '\\') {
+ i++;
+ newlen--;
+ }
+
/* Not just an empty line? */
if (newlen) {
if (empties 0 j 0)
--
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
Log messages beginning # and git rebase -i
git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. -- Ed Avis e...@waniasset.com -- 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: Log messages beginning # and git rebase -i
On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis e...@waniasset.com wrote: git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. -- 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: Log messages beginning # and git rebase -i
On Tue, Jul 28, 2015 at 6:25 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis e...@waniasset.com wrote: git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. Yeah. I recommend setting it to 'auto' so it will pick an unused character as separator (most of the time, don't push it too hard) -- 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
