<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>horsawlarway</author><text>I think you&amp;#x27;re twisting the problem statement a little here.&lt;p&gt;Asking &amp;quot;How do I unsend an email&amp;quot; is just as unreasonable as asking &amp;quot;Hey, give me that gift I gave you back&amp;quot;.&lt;p&gt;The problem is that, regardless of your intent, you&amp;#x27;ve given something to someone and they own it now.&lt;p&gt;You can&amp;#x27;t undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email).&lt;p&gt;And I want to be clear upfront - THIS IS A GOOD THING.&lt;p&gt;I don&amp;#x27;t want Amazon to be able to &amp;quot;unsend&amp;quot; my receipts.  I don&amp;#x27;t want Google to be able to &amp;quot;unsend&amp;quot; my support chat log.  I don&amp;#x27;t want my boss to be able to &amp;quot;unsend&amp;quot; his approval for my time off.&lt;p&gt;This system is designed explicitly to put the &lt;i&gt;USER&lt;/i&gt; first.  But it treats each side of the exchange as user, and values them equally - If they disagree, it&amp;#x27;s not the system&amp;#x27;s job to resolve that, they have to talk it out.&lt;p&gt;Slack and Messenger (and a lot of other modern chat) have an arbiter - They don&amp;#x27;t require users to agree because they own the content, not the users.  In a company slack, I haven&amp;#x27;t given you anything when I message you.  I&amp;#x27;ve just pinned something to the company message board.  I can take it down, and so can anyone else who has the key.  It&amp;#x27;s not mine and it&amp;#x27;s not yours - It is very clearly owned by the company.&lt;p&gt;That can work great in a well structured environment, but I have to laugh when you say its replacing email. It&amp;#x27;s not a replacement, it&amp;#x27;s a complement - They are not the same things.&lt;p&gt;Just like an oral promise with no witnesses is NOT the same as a signed receipt.  Use each as needed.</text><parent_chain><item><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></item><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><story><title>Git is too hard</title><url>https://changelog.com/posts/git-is-simply-too-hard</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>weehoo</author><text>You can’t unsend an email because you can’t force someone else to delete something.  Emails end up as files on someone else’s server.  Claiming this is a UX issue is intentionally missing the point.  If this is legitimately a foreign concept to you, an afternoon setting up postfix and playing around  with it might be worth your time.  Email is a protocol, not a program.  A “delete” request would be just that, a request.&lt;p&gt;You can “unsend” on those platforms because the GUI does not display files saved locally, it always fetches them from the server.  If you could “unsend” on a version control platform, then it would cease to be distributed version control.  The code would have to live inside the VCS app (the same way messages are in memory in slack), or you’d have to give a  network daemon delete privileges on your file system.&lt;p&gt;Imagine if youtube-dl used the model you’re proposing.  Letting the git equivalent of “unsend” propagate through the system takes you from a redundant system to, not a system with a single point of failure, but even worse, a system with many points of failure.&lt;p&gt;Git is for helping develop open source projects, where sometimes a random gal who will never show up again fixes a small thing and sends the maintainer the diff through email.  If you want a tool for the high trust environment of your individual team, git will never be what you want.  It literally wouldn’t work for its intended workflow if it did what you want.</text><parent_chain><item><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></item><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><story><title>Git is too hard</title><url>https://changelog.com/posts/git-is-simply-too-hard</url></story>