<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 07.04.2008 On Moving Gtk+ to Git</title>
	<atom:link href="http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/</link>
	<description>Technical ramblings by Tim Janik</description>
	<lastBuildDate>Sat, 11 Apr 2009 19:30:15 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Michael Trausch</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-171</link>
		<dc:creator>Michael Trausch</dc:creator>
		<pubDate>Wed, 09 Apr 2008 06:21:29 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-171</guid>
		<description>Any reason to not consider bzr?  I find it rather easy to use, and it&#039;s a GNU project now.  While I cannot offer detailed comparisons with git (I found it too hard to use at first, and have to get back to looking at it), it&#039;s got the advantages of being distributed, reasonably fast, able to work with SVN (I do so with an application I maintain for a company on a regular basis), and lets you customize/extend it locally by defining command aliases for things you often do.

Just my 2¢.  :-)</description>
		<content:encoded><![CDATA[<p>Any reason to not consider bzr?  I find it rather easy to use, and it&#8217;s a GNU project now.  While I cannot offer detailed comparisons with git (I found it too hard to use at first, and have to get back to looking at it), it&#8217;s got the advantages of being distributed, reasonably fast, able to work with SVN (I do so with an application I maintain for a company on a regular basis), and lets you customize/extend it locally by defining command aliases for things you often do.</p>
<p>Just my 2¢.  :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ovitters</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-170</link>
		<dc:creator>ovitters</dc:creator>
		<pubDate>Tue, 08 Apr 2008 11:49:55 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-170</guid>
		<description>Note that ignoring the complexity of Git by saying that you only use a subset of the commands is not at all useful.

The Git tutorials have severe drawbacks. The man pages are too complex, etc. Even just copying commands from someone else doesn&#039;t work -- you get error messages that do not make sense (e.g. that some file already exists while it doesn&#039;t).

I do not appreciate saying Git is easy, or that the complexity can be ignored -- it just isn&#039;t the case. A more constructive approach would be to check if it will be made easier in a year or so.. or that the benefits together with a frontend outweigh the complexity. 

I&#039;m not an SVN expert, I don&#039;t want to be a Git/Bzr/Hg expert. That is for others.</description>
		<content:encoded><![CDATA[<p>Note that ignoring the complexity of Git by saying that you only use a subset of the commands is not at all useful.</p>
<p>The Git tutorials have severe drawbacks. The man pages are too complex, etc. Even just copying commands from someone else doesn&#8217;t work &#8212; you get error messages that do not make sense (e.g. that some file already exists while it doesn&#8217;t).</p>
<p>I do not appreciate saying Git is easy, or that the complexity can be ignored &#8212; it just isn&#8217;t the case. A more constructive approach would be to check if it will be made easier in a year or so.. or that the benefits together with a frontend outweigh the complexity. </p>
<p>I&#8217;m not an SVN expert, I don&#8217;t want to be a Git/Bzr/Hg expert. That is for others.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jacob Kroon</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-169</link>
		<dc:creator>Jacob Kroon</dc:creator>
		<pubDate>Tue, 08 Apr 2008 10:18:58 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-169</guid>
		<description>Sooner or later people will figure out that git is not harder to use than cvs or svn, and see the benifits. But it requires that you rethink how version control works, and if necessary that you, the proud developer and expert in svn, actually ask someone else if you do not understand it.</description>
		<content:encoded><![CDATA[<p>Sooner or later people will figure out that git is not harder to use than cvs or svn, and see the benifits. But it requires that you rethink how version control works, and if necessary that you, the proud developer and expert in svn, actually ask someone else if you do not understand it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: xclaesse</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-168</link>
		<dc:creator>xclaesse</dc:creator>
		<pubDate>Tue, 08 Apr 2008 09:52:19 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-168</guid>
		<description>SVN is the worst versioning system that I know, equality with CVS. I personally like GIT, but I&#039;m sure there is other good systems like bzr...

As maintainer of Empathy I more and more think about moving to git, the only problems I have with git is when it interacts with SVN using git-svn. If we drop completely svn and move to git.gnome.org it will be *far* easier to me and other developers.

I can&#039;t understand the argument &quot;svn is easier than git&quot;, there is a small set of commands to know, like for every tools. I wrote a little howto [1] that explains how I use git for empathy coding, there is nothing hard in that.

So definitely +1 from me to move away from SVN to anything else... and git is a good candidate.

[1] http://live.gnome.org/Empathy/Git</description>
		<content:encoded><![CDATA[<p>SVN is the worst versioning system that I know, equality with CVS. I personally like GIT, but I&#8217;m sure there is other good systems like bzr&#8230;</p>
<p>As maintainer of Empathy I more and more think about moving to git, the only problems I have with git is when it interacts with SVN using git-svn. If we drop completely svn and move to git.gnome.org it will be *far* easier to me and other developers.</p>
<p>I can&#8217;t understand the argument &#8220;svn is easier than git&#8221;, there is a small set of commands to know, like for every tools. I wrote a little howto [1] that explains how I use git for empathy coding, there is nothing hard in that.</p>
<p>So definitely +1 from me to move away from SVN to anything else&#8230; and git is a good candidate.</p>
<p>[1] <a href="http://live.gnome.org/Empathy/Git" rel="nofollow">http://live.gnome.org/Empathy/Git</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yevgen Muntyan</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-167</link>
		<dc:creator>Yevgen Muntyan</dc:creator>
		<pubDate>Tue, 08 Apr 2008 09:29:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-167</guid>
		<description>Believe it or not, git is hard to use! I download cairo tarballs because &quot;git pull origin&quot; (or whatever that is, I never can remember it) sometimes fails for reasons unknown to me, and checking out a fresh copy is too slow. SVN sucks, yet it is good as a system which is to be used by lot of people, unless you are Linus or Havoc and you know that git is better for everyone else.</description>
		<content:encoded><![CDATA[<p>Believe it or not, git is hard to use! I download cairo tarballs because &#8220;git pull origin&#8221; (or whatever that is, I never can remember it) sometimes fails for reasons unknown to me, and checking out a fresh copy is too slow. SVN sucks, yet it is good as a system which is to be used by lot of people, unless you are Linus or Havoc and you know that git is better for everyone else.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rui</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-166</link>
		<dc:creator>Rui</dc:creator>
		<pubDate>Tue, 08 Apr 2008 08:54:40 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-166</guid>
		<description>&quot;
Complexity; Git is often perceived to be harder to use than SVN, there are several attempts to mitigate this problem though:  Easy Git  Giggle  yyhelp. 
&quot;

It seems there is a proliferation of these &quot;helpers&quot; recently. Have you seen Thomas Zander&#039;s[1]? It would be nice if people could collaborate with git upstream to solve the UI problem for once instead of everyone having their own &quot;home made&quot; interfaces.

[1] http://labs.trolltech.com/blogs/2008/03/30/sourcecode-collaboration/</description>
		<content:encoded><![CDATA[<p>&#8221;<br />
Complexity; Git is often perceived to be harder to use than SVN, there are several attempts to mitigate this problem though:  Easy Git  Giggle  yyhelp.<br />
&#8221;</p>
<p>It seems there is a proliferation of these &#8220;helpers&#8221; recently. Have you seen Thomas Zander&#8217;s[1]? It would be nice if people could collaborate with git upstream to solve the UI problem for once instead of everyone having their own &#8220;home made&#8221; interfaces.</p>
<p>[1] <a href="http://labs.trolltech.com/blogs/2008/03/30/sourcecode-collaboration/" rel="nofollow">http://labs.trolltech.com/blogs/2008/03/30/sourcecode-collaboration/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ovitters</title>
		<link>http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/comment-page-1/#comment-165</link>
		<dc:creator>ovitters</dc:creator>
		<pubDate>Tue, 08 Apr 2008 06:12:25 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/timj/2008/04/07/07042008-on-moving-gtk-to-git/#comment-165</guid>
		<description>There are a lot more things to consider. A replacement for svn:externals (submodules is not good enough)? I&#039;m fortunately working with Elijah as still don&#039;t understand Git, despite lots of effort. Further, use of DVCS seems to imply private repositories (in the homedir) -- things I wouldn&#039;t have considered.

Btw: SVN sync will be available in max ~2 months, I could&#039;ve provided nightly dumps if needed. Plus I agree that anything like &#039;$RCS-svn&#039; is a big hack. Oh, I&#039;m still not sold on Git (too damn complicated -- and IMO to sysadmin it, I should at least understand it).</description>
		<content:encoded><![CDATA[<p>There are a lot more things to consider. A replacement for svn:externals (submodules is not good enough)? I&#8217;m fortunately working with Elijah as still don&#8217;t understand Git, despite lots of effort. Further, use of DVCS seems to imply private repositories (in the homedir) &#8212; things I wouldn&#8217;t have considered.</p>
<p>Btw: SVN sync will be available in max ~2 months, I could&#8217;ve provided nightly dumps if needed. Plus I agree that anything like &#8216;$RCS-svn&#8217; is a big hack. Oh, I&#8217;m still not sold on Git (too damn complicated &#8212; and IMO to sysadmin it, I should at least understand it).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
