On Mon, Apr 05, 2010 at 12:58:22PM -0500, Jonathan Nieder wrote:
quoted
There's probably a lot of code out there doing `git commit -m"Yet
another revision"' from some cron job.
FWIW, I have no strong opinion about whether to add this --allow-empty-message
option. Maybe it would make something more convenient for someone,
though that has to be weighed against it making it harder for everyone
else to read the manual.
I meant to mention this in my other response: I would prefer if such an
option doesn't clutter up the usage message. --allow-empty is already
there, and probably doesn't need to be. "git commit -h 2>&1 | wc -l"
shows a whopping 39 lines, which IMHO is too many for a short usage
summary. I mean, "--no-post-rewrite", is that really one of the top-used
options?
Hint:
parent=HEAD && : or whatever &&
tree=$(git write-tree) &&
printf "%s\n" message |
commit=$(git commit-tree "$tree" -p "$parent") &&
git update-ref refs/heads/somebranch "$commit"
In addition to the bug you mention later, you also probably want to do:
parent=`git rev-parse --verify HEAD`
[...]
git update-ref \
-m 'automated commit by tool X' \
refs/heads/somebranch $commit $parent
which will give your reflog entry a more useful message, and will
protect against simultaneous updates losing history (update-ref will
make sure, while locked, that somebranch contains the $parent sha1 you
wrote as part of the commit object).
And of course it still doesn't handle parentless root commits.
So doing it right really is a bit more work than just calling "git
commit".
-Peff