Languages of the real and artificial - Latest Comments in Commit Policies

Re: Commit Policies

Gavin — Thu, 22 Jan 2009 05:26:36 -0000

Absolutely beautiful post. Thirty minutes after reading it, my whole way of doing git business has changed.

Re: Commit Policies

Andy — Wed, 30 Jul 2008 12:29:56 -0000

I have already used this article to great advantage. Might want to change the href in the large image link. It comes up as broken because you're refering to /archive/ instead of /archives/ ;)

Re: Commit Policies

Jakub Narebski — Mon, 12 May 2008 15:39:33 -0000

I wonder how Eclipse approach (local history, Mylyn,...) would interact with in-the-works Eclipse Git Plugin, aka egit (which uses jgit, which is implementation of git in Java).

Re: Commit Policies

Paul — Mon, 12 May 2008 11:24:36 -0000

Thanks so much for this coherent mental model for git. This is the first I've seen that documents Git itself, rather than just a selected list of git commands.
Your "isolated functional change" standard for committing from the index (horrible name) to the local repository is the key concept that I failed to get from learning git commands. I now see that I'd like a way to enter my intention, perhaps declaring a proposed commit message, before assembling the programming changes that will make up my next commit. In some projects, the bug-tracking system helps sort out that functional unit.
I had been thinking of my branch in some vague way as marking out that intention, but it hasn't really worked that way. I look forward to how you distinguish the function of a branch from that of a commit.
Thanks again -- this has already been very clarifying.

Re: Commit Policies

PJ — Sun, 11 May 2008 21:11:01 -0000

Are you using git to help you enforce policies? Things like having push's kick off static analysis tools or tests that have to pass before the push will succeed?

Re: Commit Policies

flevour — Sun, 11 May 2008 20:47:15 -0000

Hi there, thanks for the lovely article series. I started using git right after reading the first part. Check the first link in this post, it leads to a 404, archive in the URL needs to be plural.
And as Christian from "Anarchaia":http://anarchaia.org/archiv... wrote today, you "should write a book about Git. "

Re: Commit Policies

oli — Sun, 11 May 2008 10:33:48 -0000

I found these two articles really informative and easy to understand. Thank you! The 'commit policies' diagram is excellent. If you felt like writing more on how to use Git for the beginner that'd be great :-)
I'm doing web dev rather than programming—would you recommend doing anything different in that case? The small commits over branching matches my current SVN workflow too.
Thanks again.

Re: Commit Policies

Josh Rehman — Sun, 11 May 2008 04:21:00 -0000

Hi Oliver, love the blog - always a good read.

I don't really know git hardly at all (just from Linus's Google talk, and now from you.) However it looks like the 'index' is very similar in function to Eclipse's 'local history'. I'm not sure if you use Eclipse, but local history is a built in feature of Eclipse that lets you back out of certain changes. It can be language aware, which is nice. From your "commit policies" diagram it seems like local history is the equivalent of introducing an "add on save" policy.

For the "local repositiory" it seems that Mylyn (previously Mylar) serves that roll. Mylyn helps you collect changes into functional units even when you're working on multiple functional changes at once. Mylyn can tie those changes to a particular JIRA ticket, for example.

Finally, subversion or cvs or perforce serve as the 'remote repository'.

The Eclipse approach may seem rather haphazard (and it's certainly tied to one toolset, and not vi or emacs!) but it's interesting that the same functionality you describe is present in Eclipse, admittedly in a tool-specific fashion. Or at least thats how it sounds. I know that Linus stresses the "distributed" nature of git - in that one can replicate the repository, and host it, with great ease. While it could be said that Mylyn's shared contexts serve a similar purpose, it would be a stretch to say that the Eclipse + svn stack achieves this goal, so I must be missing something about git's workflow.

Thanks for blogging!