<story><title>Git is too hard</title><url>https://changelog.com/posts/git-is-simply-too-hard</url></story><parent_chain><item><author>thrwyoilarticle</author><text>+1. The very first question:&lt;p&gt;&amp;gt;Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?&lt;p&gt;Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don&amp;#x27;t know what git push means, you shouldn&amp;#x27;t be using it and are playing with intellectual property fire.&lt;p&gt;The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interaction with git is a disaster.&lt;p&gt;Regardless, there&amp;#x27;s no shortage of blog posts complaining about git being hard. But there is a shortage of effective, popular competitors. I think that, actually, many-chefs many-branch differential version control is just a hard problem and creating a simple model for it is much harder than complaining about git.</text></item><item><author>rakoo</author><text>&amp;gt; I’ve used it since GitHub was in beta&lt;p&gt;This is the root of the author&amp;#x27;s issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=25002318&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=25002318&lt;/a&gt;) is the complete opposite: a system that knows it&amp;#x27;s connected to other people, where changes are instantly propagated and easily visible, where the differentiator between &amp;quot;branches&amp;quot; is not &amp;quot;what computer does it reside on&amp;quot; but &amp;quot;who did it&amp;quot;. That&amp;#x27;s the model behind GitHub, after all.&lt;p&gt;git is complex because it&amp;#x27;s working with a very complicated model that is not in line with what most people expect today. As I said in my other comment it seems that fossil works with that flow, but I haven&amp;#x27;t tried it. However what is sure is that it doesn&amp;#x27;t make sense to ask git to become what it fundamentally is not.&lt;p&gt;EDIT: There might be a solution with wrappers. When you look at git-annex assistant (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;git-annex.branchable.com&amp;#x2F;assistant&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;git-annex.branchable.com&amp;#x2F;assistant&amp;#x2F;&lt;/a&gt;) you can see that the right amount of abstraction can provide something closer to what we expect... but at this point it&amp;#x27;s not git anymore, so we might as well start from scratch.</text></item></parent_chain><comment><author>wpietri</author><text>&amp;gt; You might as well ask how to unsend an email.&lt;p&gt;That is also a reasonable request.&lt;p&gt;I&amp;#x27;m unable to fathom the notion that if a computer doesn&amp;#x27;t work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.&lt;p&gt;With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. If you FedEx the envelope, you can cancel before delivery. With a university&amp;#x27;s mail system, you can get the receiving department&amp;#x27;s admin to return something even later in the chain. And of course, you can always tell a recipient, &amp;quot;Hey, I sent you the wrong box, just send that back.&amp;quot;&lt;p&gt;The reason email doesn&amp;#x27;t support unsending is not some essential property of messaging. It&amp;#x27;s just that at the time our email protocol was defined, both our hardware and software was pretty primitive, so we locked in a very primitive model of messaging. But note that more modern systems, like Slack and Facebook Messenger, happily let you unsend things. And consequently, they&amp;#x27;re effectively replacing email for most users.</text></comment>
<story><title>Git is too hard</title><url>https://changelog.com/posts/git-is-simply-too-hard</url></story><parent_chain><item><author>thrwyoilarticle</author><text>+1. The very first question:&lt;p&gt;&amp;gt;Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?&lt;p&gt;Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don&amp;#x27;t know what git push means, you shouldn&amp;#x27;t be using it and are playing with intellectual property fire.&lt;p&gt;The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interaction with git is a disaster.&lt;p&gt;Regardless, there&amp;#x27;s no shortage of blog posts complaining about git being hard. But there is a shortage of effective, popular competitors. I think that, actually, many-chefs many-branch differential version control is just a hard problem and creating a simple model for it is much harder than complaining about git.</text></item><item><author>rakoo</author><text>&amp;gt; I’ve used it since GitHub was in beta&lt;p&gt;This is the root of the author&amp;#x27;s issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=25002318&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=25002318&lt;/a&gt;) is the complete opposite: a system that knows it&amp;#x27;s connected to other people, where changes are instantly propagated and easily visible, where the differentiator between &amp;quot;branches&amp;quot; is not &amp;quot;what computer does it reside on&amp;quot; but &amp;quot;who did it&amp;quot;. That&amp;#x27;s the model behind GitHub, after all.&lt;p&gt;git is complex because it&amp;#x27;s working with a very complicated model that is not in line with what most people expect today. As I said in my other comment it seems that fossil works with that flow, but I haven&amp;#x27;t tried it. However what is sure is that it doesn&amp;#x27;t make sense to ask git to become what it fundamentally is not.&lt;p&gt;EDIT: There might be a solution with wrappers. When you look at git-annex assistant (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;git-annex.branchable.com&amp;#x2F;assistant&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;git-annex.branchable.com&amp;#x2F;assistant&amp;#x2F;&lt;/a&gt;) you can see that the right amount of abstraction can provide something closer to what we expect... but at this point it&amp;#x27;s not git anymore, so we might as well start from scratch.</text></item></parent_chain><comment><author>jrochkind1</author><text>I don&amp;#x27;t see what it&amp;#x27;s got to do with github. I had the same need, and the same confusion solving it, before I had ever used github, when I used a locally hosted git server of some kind for my team.&lt;p&gt;Do you mean it&amp;#x27;s a problem only if you are &amp;quot;git push&amp;#x27;ing&amp;quot; to a remote shared by those working on a software project?&lt;p&gt;OK, maybe. Even before github, most projects I knew of using git used that method. You can suggest nobody should, and try to educate people in a completely distributed workflow if you want, I suppose. That&amp;#x27;s not about github really.</text></comment>