[PATCH] Use the first line of commit message in "log --line"

Matthieu Moy Matthieu.Moy at imag.fr
Tue May 30 12:05:25 BST 2006


Robert Collins <robertc at robertcollins.net> writes:

> I agree with 1) for sure. The escaping for 2) is more problematic..

[...]

> and I type in:
> ====
> Change the handling of '\n' sequences so that we round trip correctly
> with broken foobar servers.
>
> ====

No need to dig that far to get an example: "accept \n as a newline
character in commit message" works too ;-) !

I was incorrectly assuming that this would be rare enough.

I can see three ways to solve this:

* Do a proper encoding, allowing \\n (double slash) to be used to
  actually say "\n". But this interacts badly with the shell, you'll
  have to use tripple slash inside double quotes ...

* Do this "\n" -> newline only in the command line, not if the message
  was entered from a text editor (obviously, in a text editor, you'd
  use real newlines, not \n !). Not 100% satisfying since you may also
  want to enter this \n litterally in the command line.

* Forget about this "\n" thing, and use another option.

I wanted to avoid the last one to avoid having one "not strictly
necessary option", since the philosophy of bzr is to avoid having too
many of them, but ...

It leaves us the choice between

1) use -s, --summary for the first line.

2) Multiple -m options allow to enter multiple lines, like:

  $ bzr -m "improved XXX" -m "rewrote function XXX.foo()" -m "added outstanding XXX.bar()"


I'm giving myself a +1 for the 1), but objections are welcome ;-).

> firstline seems a little overcomplicated. A simpler version:
> def firstline(self, string): 
> # using a type name as a variable name is frowned upon which is why we 
> # use string, not str
>     return "".join(string.splitlines()[:1])

Hmm, better stop the parsing at the first newline for performance
reasons, but there's another elegant solution below in the thread.

> That said, firstline should not be defined here : it should be on rev so
> you can go
> rev.summary_line
> or
> rev.get_summary()

Fine. I considered it as a "formatting" function, and put it beside
another formatting one, but I accept your point.

I should complete the patch within the week (but not right now).

-- 
Matthieu




More information about the bazaar mailing list