Comments on: Commit Policies http://osteele.com/archives/2008/05/commit-policies Languages of the real and artificial. Thu, 12 Feb 2009 00:20:28 -0800 http://wordpress.org/?v=2.8.5 hourly 1 By: Gavin http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-2269 Gavin Thu, 22 Jan 2009 07:26:36 +0000 http://osteele.com/2008/05/10/commit-policies#comment-2269 Absolutely beautiful post. Thirty minutes after reading it, my whole way of doing git business has changed. Absolutely beautiful post. Thirty minutes after reading it, my whole way of doing git business has changed.

]]> By: Andy http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-500 Andy Wed, 30 Jul 2008 16:29:56 +0000 http://osteele.com/2008/05/10/commit-policies#comment-500 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/ ;) 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/ ;)

]]> By: Jakub Narebski http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-494 Jakub Narebski Mon, 12 May 2008 19:39:33 +0000 http://osteele.com/2008/05/10/commit-policies#comment-494 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). 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).

]]> By: Paul http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-499 Paul Mon, 12 May 2008 15:24:36 +0000 http://osteele.com/2008/05/10/commit-policies#comment-499 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. 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.

]]> By: PJ http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-498 PJ Mon, 12 May 2008 01:11:01 +0000 http://osteele.com/2008/05/10/commit-policies#comment-498 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? 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?

]]> By: flevour http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-497 flevour Mon, 12 May 2008 00:47:15 +0000 http://osteele.com/2008/05/10/commit-policies#comment-497 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/archive/2008/05/11.html wrote today, you "should write a book about Git. " 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 wrote today, you “should write a book about Git. “

]]> By: oli http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-496 oli Sun, 11 May 2008 14:33:48 +0000 http://osteele.com/2008/05/10/commit-policies#comment-496 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. 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.

]]> By: Josh Rehman http://osteele.com/archives/2008/05/commit-policies/comment-page-1#comment-495 Josh Rehman Sun, 11 May 2008 08:21:00 +0000 http://osteele.com/2008/05/10/commit-policies#comment-495 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! 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!

]]>