I spent just my last night going through few months worth of patches and cherry-picking the bugfixy ones to glibc’s release/2.11/master. But I was tired and didn’t pay attention to git’s messages, so at the end of the evening, I noticed that for all conflicting patches, I have done
git commit -a instead of
git commit -a -c commitid. This had a definite advantage since the “(cherry picked from commit …)” notices inserted by
git cherry-pick -x got preserved, but also a very definitive problem – the author name and date info for each commit was wrong.
(Note that AIUI, 1.7.5 cherry-pick might not have this problem anymore. I’m still using 1.7.4, content with Debian’s packaged version nowadays.)
Due to the -x lines, we still have mapping to original history. Therefore, some scripting should fix this quickly. And sure enough…! Maybe this recipe will come useful to someone:
git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "Petr Baudis" ]; then
# Author of this commit is wrong! We could also simply correct
# all commits containing the "cherry picked" notice.
cat >/tmp/logm$$ # save log message
ocommit="$(sed -n '\''s/^(cherry picked from commit \(.*\))$/\1/p'\'' </tmp/logm$$)"
# Load original authorship information:
IFS=: read GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE \
<<<"$(git log -1 --pretty=format:"%an:%ae:%at" $ocommit)"
# Redo the commit:
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
git commit-tree "$@" </tmp/logm$$
git commit-tree "$@" # preserve commit intact
Note that this requires that /bin/sh is bash (which may NOT be the case on debian!). Otherwise, you need to rewrite the <<< bit.
The c55cc45ed… commit is the first wrong cherry-pick. You may omit that altogether if you wish but the complete branch history is going to be rewritten. Also note that you should never rewrite commits that are already pushed out to a public place.
I would like to announce Girocco-1.0, the first stable release of a universal Git project hosting infrastructure. You can get it at
You guessed right, Girocco is the software repo.or.cz runs at; however, compared to the past, it’s much cleaned up, cleanly packaged for easy re-deployment and fully configurable, thanks to sponsorship of Novartis and Novell. (Apologies for switching repo.or.cz to it and
releasing it one year later than it should’ve been done.)
Thus, you should be able to easily deploy a local Girocco instance at your site and configure it to do only what you want. Girocco allows both full push-based project hosting, or just mirroring and showing existing projects (either local or remote) – i.e. you can also use it just to collect scattered repositories of your developers and present them all at single place. The push-based hosting offers currently two models, chroot hosting and hooks-based permissions (for trusted environments) – it should be easy to add other models.
This way, Girocco might present an interesting alternative to Gitorious for people who prefer mirroring over full project hosting, prefer then rawer gitweb interface ;-), like the repo.or.cz simple forking model or want to make use of the GitHub-like flexible commit notifications mechanism.
(If you are actually going to deploy Girocco somewhere, it’s good to tell me so that I can take it into account to e.g. provide upgrade paths for future Girocco changes.)
If you are used to repo.or.cz, what’s new in Girocco at the user’s end?
- Friendlier homepage.
- Friendlier project/user management interface.
- Friendlier mirror cloning process (you can see the progress in your browser).
- Support for automatic Git mirroring of SVN repositories. (Only very simple, stdlayout only.)
- Support for new-commit notifications, both for push and mirror project modes:
- Get a notification to specified mail address(es)
- Get a notification by receiving a POST HTTP request with GitHub-compatible JSON payload
- Have repo.or.cz send commit notifications to the CIA service
- Much easier to contribute a change to Girocco if you are missing any feature on repo.or.cz!
Enjoy! (Original announcement.)