On Wed, 16 Apr 2014 02:25:33 -0700 (PDT)
Yves Goergen yves.goer...@gmail.com wrote:
I'm writing a build automation script (with PowerShell) for my
project and one of its tasks is to write all commit messages since
the last publishing into a text file so that I can edit the messages
into a simplified form for the user. (That's a kind of change log
file for the user that only goes down to the level of releases, not
every single commit.)
This is already implemented for Subversion using the SVN command line
client. That program has a nice option to output the requested log
entries in XML format which is reasonably easy to parse with
PowerShell. Unfortunately, Git doesn't have this option. In fact it
doesn't even support any machine-readable output format for log
entries.
I'd like to suggest adding the XML output format to the git log
command so that this information can be parsed without any
uncertainties caused by the actual commit message content. I don't
care much about the exact XML schema. The SVN schema may serve as a
starting point, but Git probably needs other elements for its data.
IMO, hardcoding support for XML representation of the log data is a
perfect anti-pattern. A simple test to classify it as such is why
XML and not JSON, BSON, YAML, S-expressions or one of other existing
and popular 100500 ways of representing structured data?.
To reliably parse commit metadata with the tools already available you
should go one level deeper (to the so-called plumbing level).
There, instead of `git log`, use `git rev-list`, which prints out
SHA-1 names of all the commits matching the specified range(s), one on
a line, iterate over this output, and extract the commit object for
each SHA-1 name read using the `git cat-file commit sha1name`.
The commit object has a very simple structure:
Key : SP Value LF
[Key ...]
LF
Message
Where SP stands for a single ASCII space character (0x20) and LF stands
for a single ASCII line feed character (0x0d).
The Message is *by policy* consists of a short message (up to 50
characters) followed by a blank line followed by a descriptive part.
`git cat-file` also supports the --batch command-line option which
enables it to consume the output of `git rev-list` directly and produce
a stream of parsable data (see the manual page) but the runtime the
parser is implemented in has to be able to read data in chunks of
arbitrary sizes to use with this format.
To conclude, if Powershell fails at any of the requirements outlined
above to parse the output of the Git's plumbing tools, consider
delegating some of this work to the bash shell which is distributed
with Git for Windows anyway (as some of the Git tools, namely,
`git rebase`, rely on it).
Another option would be to use JScript or VBScript via WSH instead of
Powershell -- the latter is sort of cool but it's not a real
programming language while WSH is almost there. At least it's trivial
to convert a commit object output by `git cat-file` to a piece of XML
using JScript. You could also use Perl of Tcl which are distributed as
part of Git for Windows as well -- both are perfect picks for
advanced text processing (I'm personally biased towards the latter).
Unfortunately I haven't found a bug tracker or other web forum for
this kind of conversation. Mailing lists are a pain to set up on my
side and not accessible from the web. This forum seems to be the only
accessible way to get in contact with the Git developers.
No, this list is not read by the actual Git developers, so posting bug
reports here is unfortunately almost pointless. The best place to
discuss bugs and features is the main Git list [1], but yes, it seems
to not be accessible using some sort of web interface.
1. https://gist.github.com/tfnico/4441562
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
