git log --pretty=format joins lines in the subject of commit message

Commit something to a git repository with a commit message with several newlines like this:

==== commit message starts below === first line second line third line

fifth line === commit message ends above ===

Git treats the first 3 lines as commit message subject and the last line as its body.

'git log' shows the commit message correctly - exactly like I've entered. So does 'git log --pretty=raw'

But 'git log --pretty=format:%s#%b' joins the first three lines: first line second line third line#fifth line

Is it a bug or a feature? If it is a feature how can I acquire the original subject of the commit message by using custom format?

Thanks a lot.

---------------------------------- Kirill Likhodedov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!"

On Wed, Sep 15, 2010 at 12:55, Kirill Likhodedov <Kirill.Likhodedov@jetbrains.com> wrote:

It's probably a feature. We delimit the subject by "\n\n", not "\n". And IIRC subjects in E-Mail can contain \n.

Use a log format that gives you the complete message, then pipe it through perl or something to parse it?

I think that if it is a feature, it should be reflected in the documentation for custom pretty formats.

Anyway, that doesn't seem consistent enough: Git knows that the subject is "first line\nsecond line\nthird line" (because it shows it correctly in full or raw formats). Why does it join the lines in the custom format's %s? 

I know I can just use raw format, I'm just concerned about git log behavior consistency.

15.09.2010, в 17:01, Ævar Arnfjörð Bjarmason написал(а):

---------------------------------- Kirill Likhodedov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!"

On Fri, Sep 17, 2010 at 03:56:53PM +0400, Kirill Likhodedov wrote:

I agree it should be documented. I'm not sure where, though. The subject-munging affects more than just pretty formats. For example, at least git format-patch also has --keep-subjects to turn off munging. I guess a note should be made in a all relevant places.

Because then the consumer of "git log --format=%s" knows that they will get exactly one line per commit.

The convention in git is to do "subject\n\nbody", with subject on a single line. However, we often see commits imported from other version control systems without this format. The subject-munging is an attempt to make them useful in git-aware tools (e.g., gitk or gitweb, which show the subject). Showing just the first line of a multi-line subject is often useless. People complained, and we got the behavior we have today.

-Peff

All,

I'm converting repositories from svn to git using svn2git.  I have a repo with the following hierarchy:

trunk/ dist/ tags/ branches/ REbranches/

Ultimately I want to convert everything except the dist directory but am trying to understand what svn2git is doing and why.

I ran the command to see what I would get just importing trunk:

svn2git -v --nobranches --notags  http://poc.emc.com/repos/POCcs

After the conversion completed I had the following:

buildadm@suse-s11:/work/POCcs> ls Automation build_cs_rpm.pl ControlStation depends.properties

Then I ran the following command because I wanted to include the branches as well as the trunk in the conversion:

svn2git -v --notags  http://poc.emc.com/repos/POCcs

When I include the branches in the conversion I get a Build directory at the top level and then the usual directory structure of the repo.  Where is the Build dir coming from?  Is svn2git doing that?  Or is it finding that somewhere somehow in the repo?

buildadm@suse-s11:/work/POCcs> ls Build buildadm@suse-s11:/work/POCcs/Build> ls Automation build_cs_rpm.pl ControlStation depends.properties

Thanks for any help.

Nolan

Sidenote: You shouldn't reply to unrelated messages when starting a new 
thread. In my mail client this shows up as a reply to "git log --pretty=format 
joins lines in the subject of commit message" which doesn't seem to have 
anything to do with your question.

On Wednesday 15 September 2010 09:47:42 nolan.ring@emc.com wrote:

Assuming the files are tracked by git, you might want to try running "git log -- $filename" over them to see which commits touched them.

I'm replying here as I just joined the list and missed the original message.

This is an error in your rule files.

/Regards Torgny