Manually setting the authored date in a git commit

Posted by Tim Connor Mon, 13 Oct 2008 05:04:00 GMT

After my last post about splitting and otherwise reworking git commits via rebase I needed a way to manually set the authored date on a git commit, since I had overwritten that on some old commits. And having earlier commits come a month after later ones looks a bit silly. So I searched around in vain for how to set that field manually.

Thankfully, deskin on #git was able to quickly point me in the right direction. The docs for git-commit-tree talk about the environmental variables that determine the date, author, etc. Git commit honors these (at it probably actually uses git-commit-tree, behind the scenes). So to change the date on a commit (in the middle of a git-rebase, git-reset just set the environmental variable inline, thus (if you use bash):

GIT_AUTHOR_DATE=‘2008-09-29 01:09:07’ git commit

This will not work on an —amend, though, since that is intended to just keep the same time and other settings for the commit, but just add some more changes. These means to change the time you must follow the more complicated workflow in my previous post.

Editing git commits with rebase, in particular splitting commits

Posted by Tim Connor Mon, 13 Oct 2008 04:44:00 GMT

So I have a project on github that I wanted to rework some of the commits before anyone sees them. I used to manage the project via svk, so the commits are squashed down into less granular blocks than I want for reviewing via an interface like githubs. ‘git commit —amends’ for, well, amending the last commit you made, but if the changes are further back than that, you get into the deep magic of rebasing. Much of this is discussed in the man pages, and docs for git-rebase but that can be hard to follow until you really understand what is happening.

‘git-rebase -i SHA_OF_PARENT’ lets you rollback to the commit before where you want to start mucking with stuff, mark which commits you want to edit, and then recommit them. For the simplest use case, just editing the commit messages, you just ‘commit —amend’ each time git-rebase pauses, ‘git-rebase —continue’ and repeat until done. This workflow is explained reasonably well in the docs, the only thing to emphasize that will help you understand the more complex cases is that it works by rebase pausing just after each commit you marked for editing, so that you can amend (which amends that last commit) and continue.

This segues into how splitting up of commits works. You mark for editing and rebase as usual. When it pauses after the commit you want to split up, you ‘git reset HEAD^’ to rewind one commit, while keeping the changes in the filesystem. So at this point, if you committed and continued, it’s be exactly like the simpler workflow. Instead, though, you can split up the changes: git add each subset of changes, committing them with the appropriate message. Then when you are done, rebase —continue again.

With these techniques you can rework the history completely into a better organized, more easily follow-able set of chunks. It does leave a couple problems, if it is a repo you have already pushed you will get a ‘not strictly subset’ error. If you know nobody has pulled from it, you can just push —force, but I make no guarantees what this might do to the state of other peoples repos that are pulling from the same master, especially if they are mucking about similarly.

The other problem is that this resets the authored by date on the commits, since it’s essentially nuking one commit and making a new one. I’ll discuss this in the next post manually setting the authored date in a git commit


Trouble with git-svn locating svn perl language bindings - Can't locate SVN/

Posted by Tim Connor Sun, 21 Sep 2008 03:45:00 GMT

If you get an error “Can’t locate SVN/” when trying to use git-svn, it cannot find your perl bindings. After endless troubles trying to get things to either compile from source, or from macports (a dependency, apr_util, would not compile on my system), and with no luck with the binaries I was frustrated. But I finally found a blog post that told me I had to set the $PERL5LIB environmental variable, if I was getting that error.

So I added “export PERL5LIB=/opt/subversion/lib/svn-perl/” to the end of my .profile, and I was good to go.

http access to blerb via gitweb and general update.

Posted by Tim Connor Tue, 11 Dec 2007 07:42:00 GMT

hornbeck’s master repo is available at git:// Stop by #blerb if you want to hack on it. With the help of mattly and court3nay I’ve put a copy of the repo up at so now there is web access to blerb source via gitweb, for those who don’t want to brave git, yet, or who already have access to (I believe it’s wide open for read-only, of course), or just those that like browsing the history/changelogs/ through a webterface. I’ll be pushing up to there every so often.

On another note, we plan on borrowing everything that makes sense to from Ezra’s earlier stab at a similar project: MrBlog

Setting up git over webdav with anonymous access for read-only and password protected commit rights - blerb git repo available 2

Posted by Tim Connor Mon, 03 Dec 2007 05:11:00 GMT

Some useful info on the DH wiki for git and on’s guide to setting up git over http. The latter is especially helpful for debugging suggestions (like using curl to check your .netrc access permission). Using the info in these guides:

  • Create a repo, or use an existing one
  • Enable WebDav access on a DH directory, using their panel. Set-up the username password for the committers, and disable the password protection box for read-only anonymous access (might be easier to keep it on until you have everything set-up right)
  • Create a .netrc with the auth info for this webdav
  • Test your access using the curl command in the guide (you may find it useful to have password protection enabled at this point,).
  • Connect to the webdav share using the username and password.
  • Copy over the .git folder contents into the root of the webdav share (this is key, because DH’s anonymous access won’t show . files)
  • cd into the webdav share from your local machine and run “git-update-server-info”
  • profit

You should now have access to http://yourserver/gitfoldername and http://gituser@yourserver/gitfoldername. For example: you can “git clone” for read-only access to the blerb repo. Now, if I can only get gitweb working despite the limited access control imposed by DH webDAV.

Update: Changes the url for blerb to still work right after I changed it around while playing with gitweb. Also, you should use git:// if you actually want the real blerb repository.