Hi guys,

We're using git version 1.7.1, and when this module fetch commit operations it issues the following command, found in VersioncontrolGitRepositoryHistorySynchronizerDefault.class.php and the function parseAndInsertCommit():

<?php
$command = "show --numstat --summary --pretty=format:\"%H%n%P%n%an%n%ae%n%at%n%cn%n%ce%n%ct%n%B%nENDOFOUTPUTGITMESSAGEHERE\" " . escapeshellarg($hash);
?>

In our environment this seems to result in the "message" column of db-table "versioncontrol_operations" containing "%B" instead of the commit-message. I therefore started investigating the behavior, and in the process issued the command manually:

(I took the liberty of anonymizing it a little)

[root@server directory]# GIT_DIR=/my/git/repo/path/testing.git /path/to/bin/git show --numstat --summary --pretty=format:"%H%n%P%n%an%n%ae%n%at%n%cn%n%ce%n%ct%n%B%nENDOFOUTPUTGITMESSAGEHERE" '<hash1>'
<hash1>
<hash2>
<my username>
email@example.com
1341180316
<my username>
email@example.com
1341180316
%B
ENDOFOUTPUTGITMESSAGEHERE
2       1       testing.txt

Surely enough the %B seems present there too instead of the actual commit-message. So I decided to look up the manual on the "pretty" formating to double-check what the appropriate option/placeholder would be.

http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History

This lists the available options/placeholders as:

Option  Description of Output
%H  Commit hash
%h  Abbreviated commit hash
%T  Tree hash
%t  Abbreviated tree hash
%P  Parent hashes
%p  Abbreviated parent hashes
%an Author name
%ae Author e-mail
%ad Author date (format respects the –date= option)
%ar Author date, relative
%cn Committer name
%ce Committer email
%cd Committer date
%cr Committer date, relative
%s  Subject

I assumed "Subject" is what we are after here - so I tested with that instead:

[root@server directory]# GIT_DIR=/my/git/repo/path/testing.git /path/to/bin/git show --numstat --summary --pretty=format:"%H%n%P%n%an%n%ae%n%at%n%cn%n%ce%n%ct%n%s%nENDOFOUTPUTGITMESSAGEHERE" '<hash1>'
<hash1>
<hash2>
<my username>
email@example.com
1341180316
<my username>
email@example.com
1341180316
ref [65] Another (2nd) commit to testing repo.
ENDOFOUTPUTGITMESSAGEHERE
2       1       testing.txt

And indeed it works!

Is there an error in your implementation of the "pretty" formating here, or have I missed something?

Perhaps there's been a change in format in later git versions?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sigveio’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev

Sorry, tagged it the wrong version.

marvil07’s picture

Title: Incorrect option/placeholder in "pretty" formating » Backport git version check on hook_requirements
Category: bug » task

Thanks for taking the time to write this.

The formatting used there has changed many times, and actually we introduced the body placeholder since that's what we were actually needing. Before that we were using %s%n%b, but that had a problem(details on #1075702: Commits page does not preserve line breaks in commit messages).

A hook_requirements has been added, but sadly only in 7.x-1.x, where we check for git version, which now is 1.7.0.5(that's the 1st version including %B placeholder, see git upstream 1367b12ad623e28546ba40c435015d94e7fbb248) as minimum value.

So, instead of closing this as won't fix, I have changed the title, and I would be happy to add that hook_requirements in 6.x-2.x.

Patches welcome!

sigveio’s picture

Thanks for the prompt feedback. :)

As mentioned we run 1.7.1, which is a higher version than 1.7.0.5, yet our environment does not support it. Judging by their documentation in the git main repo, it doesn't look like it was introduced until 1.7.2. (Frankly it's a bit sloppy for their online documentation / book to not feature the option 2 years down the road..)

I'd put up a note on the module description regarding minimum git version (and how to check for it "git --version") to make sure people are aware, in addition to the hook_requirements backport.

sdboyer’s picture

we had problems with this at the sprint in portland back in april, which is when we introduced the hook_requirements implementation. i thought we traced it back to 1.7.0.5, but that was a pretty harrowing day. so if you're having the problem on 1.7.1, then sure, let's scoot it to 1.7.2. i've added a note to that effect on the project page.

marvil07’s picture

Let's do the backport

tizzo’s picture

Assigned: Unassigned » tizzo

working on this

tizzo’s picture

tizzo’s picture

Status: Active » Needs review
marvil07’s picture

Status: Needs review » Fixed

Thanks for the patch :-)

I have added two minor changes to it:

And it's now on 6.x-2.x

sigveio’s picture

Good job, guys. :) *pat on back*

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Clarified a paragraph