Re: Log messages beginning # and git rebase -i

Matthieu Moy 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

Re: Log messages beginning # and git rebase -i

Junio C Hamano writes: > Matthieu Moy writes: > >> Duy Nguyen writes: >> >>> On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy >>> wrote: > If the user wants whatever she types in the resulting commit > literally, there is the "--cleanup=" option, no? $ GIT_EDITOR=touch git comm

Re: Log messages beginning # and git rebase -i

Matthieu Moy writes: > Duy Nguyen writes: > >> On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy >> wrote: If the user wants whatever she types in the resulting commit literally, there is the "--cleanup=" option, no? >>> >>> $ GIT_EDITOR=touch git commit --cleanup=verbatim >>> [detached

Re: Log messages beginning # and git rebase -i

On Wed, Jul 29, 2015 at 7:17 PM, Matthieu Moy wrote: > Duy Nguyen writes: > >> On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy >> wrote: If the user wants whatever she types in the resulting commit literally, there is the "--cleanup=" option, no? >>> >>> $ GIT_EDITOR=touch git commit --

Re: Log messages beginning # and git rebase -i

Duy Nguyen writes: > On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy > wrote: >>> If the user wants whatever she types in the resulting commit >>> literally, there is the "--cleanup=" option, no? >> >> $ GIT_EDITOR=touch git commit --cleanup=verbatim >> [detached HEAD 1b136a7] # Please enter the

Re: Log messages beginning # and git rebase -i

On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy wrote: >> If the user wants whatever she types in the resulting commit >> literally, there is the "--cleanup=" option, no? > > $ GIT_EDITOR=touch git commit --cleanup=verbatim > [detached HEAD 1b136a7] # Please enter the commit message for your change

Re: Log messages beginning # and git rebase -i

Thank you for looking into this. -- Ed Avis -- 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 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

Re: Log messages beginning # and git rebase -i

Matthieu Moy 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 "doubl

Re: Log messages beginning # and git rebase -i

Junio C Hamano writes: > Matthieu Moy 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

Re: Log messages beginning # and git rebase -i

I was considering this case: - git commit -a '-m# characters are now handled OK' - hack, hack - git commit -a '-mWhoops, fixed last commit' - run git-rebase -i - squash the second commit into the first - when prompted for the log message for the combined change, delete the "Whoops, fixed last co

Re: Log messages beginning # and git rebase -i

Matthieu Moy writes: > Ed Avis writes: > >> Eric Sunshine 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 r

Re: Log messages beginning # and git rebase -i

Ed Avis writes: > Eric Sunshine 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 a

Re: Log messages beginning # and git rebase -i

Eric Sunshine 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

Re: Log messages beginning # and git rebase -i

On Tue, Jul 28, 2015 at 6:25 AM, Eric Sunshine wrote: > On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis 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 beg

Re: Log messages beginning # and git rebase -i

On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis 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

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