Hi Daniel, On Mon, 9 Jul 2018, Daniel Harding wrote: > On Mon, 09 Jul 2018 at 00:02:00 +0300, brian m. carlson wrote: > > On Sun, Jul 08, 2018 at 09:41:11PM +0300, Daniel Harding wrote: > > > Signed-off-by: Daniel Harding <dharding@xxxxxxxxxxxxx> > > > > > diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh > > > index 78f7c9958..ff474d033 100755 > > > --- a/t/t3430-rebase-merges.sh > > > +++ b/t/t3430-rebase-merges.sh > > > @@ -56,12 +56,12 @@ test_expect_success 'create completely different > > > structure' ' > > > cat >script-from-scratch <<-\EOF && > > > label onto > > > - # onebranch > > > + > onebranch > > > pick G > > > pick D > > > label onebranch > > > - # second > > > + > second > > > reset onto > > > pick B > > > label second > > > > Should this affect the "# Merge the topic branch" line (and the "# C", > > "# E", and "# H" lines in the next test) that appears below this? It > > would seem those would qualify as comments as well. > > I intentionally did not change that behavior for two reasons: > > a) from a Git perspective, comment characters are only effectual for comments > if they are the first character in a line > > and > > b) there are places where a '#' character from the todo list is actually > parsed and used e.g. [0] and [1]. I have not yet gotten to the point of > grokking what is going on there, so I didn't want to risk breaking something I > didn't understand. Perhaps Johannes could shed some light on whether the > cases you mentioned should be changed to use the configured commentChar or > not. > > [0] > https://github.com/git/git/blob/53f9a3e157dbbc901a02ac2c73346d375e24978c/sequencer.c#L2869 > [1] > https://github.com/git/git/blob/53f9a3e157dbbc901a02ac2c73346d375e24978c/sequencer.c#L3797 These are related. The first one tries to support merge -C cafecafe second-branch third-branch # Octopus 2nd/3rd branch i.e. use '#' to separate between the commit(s) to merge and the oneline (the latter for the reader's pleasure, just like the onelines in the `pick <hash> <oneline>` lines. The second ensures that there is no valid label `#`. I have not really thought about the ramifications of changing this to comment_line_char, but I guess it *could* work if both locations were changed. Ciao, Johannes
