Hacker News Reader

Comment by thrwyoilarticle | Hacker News Reader

+1. The very first question:

>Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?

Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire.

The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interaction with git is a disaster.

Regardless, there'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.

View on HN

> You might as well ask how to unsend an email.

That is also a reasonable request.

I'm unable to fathom the notion that if a computer doesn'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.

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's mail system, you can get the receiving department's admin to return something even later in the chain. And of course, you can always tell a recipient, "Hey, I sent you the wrong box, just send that back."

The reason email doesn't support unsending is not some essential property of messaging. It'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're effectively replacing email for most users.

> The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined,

email supports unsending in exactly the same ways you described for packages. It most definitely is a property of messaging.

Your fron porch is called "outbox". works the same - you can delete from outbox before sending.

If both you and your recipient are on a properly configured Microsoft Exchange server, you can unsend a message, which is similar to the university department.

And if you aren't, you can still send a message saying "hey, please don't open the last email", and it's up to the other side if they do or don't.

For better and worse, email has a lot of similarity to real mail, down to the distinction between content and envelope.

The main difference is the speed of delivery - you would not expect any of the ways you suggested to work 3 months after you've sent your package -- and yet, compared to the 500ms or so that it takes the email to reach the recipient, that's what attempting to unsend after one minute is.

I think you're twisting the problem statement a little here.

Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back".

The problem is that, regardless of your intent, you've given something to someone and they own it now.

You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email).

And I want to be clear upfront - THIS IS A GOOD THING.

I don't want Amazon to be able to "unsend" my receipts. I don't want Google to be able to "unsend" my support chat log. I don't want my boss to be able to "unsend" his approval for my time off.

This system is designed explicitly to put the USER first. But it treats each side of the exchange as user, and values them equally - If they disagree, it's not the system's job to resolve that, they have to talk it out.

Slack and Messenger (and a lot of other modern chat) have an arbiter - They don't require users to agree because they own the content, not the users. In a company slack, I haven't given you anything when I message you. I've just pinned something to the company message board. I can take it down, and so can anyone else who has the key. It's not mine and it's not yours - It is very clearly owned by the company.

That can work great in a well structured environment, but I have to laugh when you say its replacing email. It's not a replacement, it's a complement - They are not the same things.

Just like an oral promise with no witnesses is NOT the same as a signed receipt. Use each as needed.

I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not impossible for a version control system to work like that and the point of any software is to help them do what they're trying to do.

This doesn't mean that Git has to accept any feature under the sun and it might be that Git isn't most appropriate tool for teams that want such a feature. But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.

VCS exist to make it possible to organize and track changes to project source code. Convenience of the user is a secondary goal to clear organization and code management.

A VCS shouldn't be unnecessarily difficult to use, but the fact that this conversation around Git's UX is endlessly rehashed is proof that version control is a hard problem.

If there was an easy and obvious 10x improvement over Git it would have replaced Git by now. Or to put it differently, when someone makes an easy 10x improvement over Git, it will see widespread adoption.

I don't think that last bit is necessarily true. Git has strong network effects, and people are generally very conservative about tools like source control. Git also has the benefit that there are a lot of people used to its quirks, and that skill investment makes them feel fond of it.

The same was true with the switch to WYSIWYG OSes and word processing tools; they were generally liked by people new to computing, but people who were steeped in the old ways, many switched only reluctantly.

The trees are brutal here. Someone pushed the code a minute ago, but I've fetched it already and now I'm editing the same source file.

If you take it away from me, or make me later inadvertently push their code, you are inconveniencing an innocent person.

> But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.

Yes, yes there is.

I've worked in systems like you're describing (CVS, SVN) - The problem is that they ALL require locking.

Locking freaking sucks. It sucks SO INCREDIBLY MUCH more than dealing with the complexity of a real distributed system that git won, even though its cli interface is a god-damned nightmare.

You clearly haven't had a co-worker lock a file you need to edit and then go on vacation.

> I have to laugh when you say its replacing email.

Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they shifted to mediums better suited. Just this morning I had to FB message a few friends to get their current email addresses, which tells me a lot about who's winning.

Yes, I agree there are times you don't want things unsent. And there are times you do. There are a variety of ways to balance these concerns. But exactly none of them involves saying, "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."

Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel. It reminds me of this Douglas Adams quote:

"I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the natural order of things."

Sure, I get that a lot of people were born after RFC 822, so it seems like the natural order. But the people who wrote the early RFCs weren't thinking that way, and neither should we.

I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends.

At no point did I appeal to authority or history in my argument above, so drop the shit around

> "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."

---

If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

> drop the shit around

You jumped into a discussion. The person I replied to was treating the email we happen to have as some sort of unchangeable given. That's what I am objecting to. If you are disavowing that side of his argument, feel free to say so, but it looks to me like you lean pretty heavily on it.

> let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

You mean aside from the billion or so users of WeChat Pay?

> It's not a replacement, it's a complement

> [Chat apps] can work great in a well structured environment

> Use each as needed

> I also tend to use discord/steam for throw-away conversation with friends

Yes, clearly I'm only advocating for the use of email in its current form for all communication, see me lean so hard above?

---

Wechat might as well be the Chinese government, and it requires a Chinese/Hong Kong bank account to use Wechat Pay. If the government won't honor your transaction record, keeping a copy yourself isn't very useful...

> If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

https://www.amazon.com/gp/help/customer/display.html?nodeId=...

Sure, but it's limited to mobile numbers where an sms provides the same value as a proof of record. That's why it's limited to mobile phones.

And SMS operates with the same functional principle as email - I own the text after receiving it, and can use it as needed.

> If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

You can do pretty much anything you want in WeChat, and you don't need an email.

Ok, this one is entirely fair, but also I'd argue the circumstances around it are a little different.

Given how tightly integrated wechat is with the chinese government, and the restriction of wechat pay to use with folks who have a Chinese/Hong Kong bank account, we're talking about different levels of utility around preserving the record.

If the government chooses not to honor your transaction record, it doesn't really matter if you have a copy yourself.

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.

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.

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.

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.

Thanks for the explanation, but I ran mail servers for ~25 years. I am familiar with the technology, and in the mid-90s even wrote a chapter of a book explaining email. And I've been using version control even longer. Maybe try rereading what I wrote without the assumption that it comes from ignorance.

I think your comments are coming from ignorance, though.

Without trying to be snarky - All your comments directly ignore that what you're proposing values one stakeholder more highly than another.

People keep pointing out that there are two users involved in this exchange, and they both weigh equally, and you dismiss them and talk about running mail servers 25 years ago (who cares?).

You keep saying "I should be able to unsend my email". Let me rephrase your question - Why should you be allowed to delete my email?

I have in fact never said "I should be able to unsend my email". Once. In my life. Please try to argue with my actual points; I don't have time for straw men.

wpietri:

>Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel.

---

We're here answering affirmatively that "No" is the right answer for a LOT more reasons than an appeal to authority and history, and you accuse me of a strawman?

I wish you the best in life. Have a good day.

Yes, I am indeed accusing you of a strawman. You seem very much in the discussion to win it, whatever that means to you. I can only hope that, having decided you are victorious, you'll now leave me alone, because none of your comments seem particularly productive to me.

> Emails end up as files on someone else’s server.

When I use my Gmail account to send an email to another Gmail user, this is obviously not the case. Many adults in their twenties have never used a desktop email application - at my company the younger new hires need some time to figure out how to use Outlook, and they're engineers. They've grown up with the cloud as a given, local storage as the exception, and centralized messaging apps as the default method of communication.

I'm not going to argue about whether way of thinking about computing is any better or worse, but undeniably convenient, and it's definitely the direction we're headed.

>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer.

You don't understand because you think you're fighting computers but you're actually at odds with other human's desires.

If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you deleted.

You can easily change the history technologically. You just force push what you want. The issue is that is usually disabled because it causes a lot of problems for everyone else on the team.

That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology.

I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to prevent A from un-pushing. Even if person B has pulled, a propagating un-push might well be what they want. I generally would. There are certainly some cases where B might not want that, but given that undoability is a has become a strong user expectation, I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.

>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.

Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.

> I'm unable to fathom the notion that if a computer doesn'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.

If you try to do that too hard you run into the task automation problem:

https://xkcd.com/1319/

In other words, "make the computer do things for me" as a diminishing returns problem. This is what you don't get.

What works best is a user-tool co-evolution. If I'm not mistaken, this is one of the core ideas of the Agile manifesto.

“We become what we behold. We shape our tools, and thereafter our tools shape us.” Marshall McLuhan

I don't see what it'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.

Do you mean it's a problem only if you are "git push'ing" to a remote shared by those working on a software project?

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's not about github really.

They're complaining about git and the very first thing they discuss is how git interacts with a completely separate piece of software. Push doesn't have to be to Github, it can also mean sending an email. Obviously you can't undo that.

The Github-first problem is viewing git merely as an interface to Github, where the home of the work is and where all things are collected and operated on. From this it follows that git push is a fundamental operation like add or commit. And from this follow complaints that git commit isn't something that sends your changes to the One True Repo.

If you push then you should give up any expectation of control or ownership over the code that's sent over the communications protocol of choice. Purging a file is nice for you but in action would be a force-pushed rebase that you have to ask people very nicely to use instead of the initial branch. Controlling what branch other people use is completely out of scope for a local VCS.

The blog continues on to say that the distributed nature gets in the way of the mental model.:

>they have never even considered that there’s such a thing, because why would they? A branch is just a single concept in our head that is made complicated by the inherent distributed nature of Git.

And that's just the wrong model to have, inspired by understanding git through the lens of Github. If you're using git and you're unaware that you're operating on your local copy, not a shared workspace, then you can't place much stock in whatever mental model you come up with.

OK, I understand you think the way most actual use of git I have observed takes place is "the wrong model to have". That is an opinion you can have, and you can try to convince people of it; to be succesful at doing that, you probably want to understand what motivations and pressures lead to this style of use in the first place; why do you think so many (from my view, the majority of git users), choose to use git in this "wrong" way?

It still has nothing to do with github specifically. It is also true of people using gitlab. Before github existed, I (and many other teams I know) used a variety of other ways of hosting a remote git server shared by the team, including various open source software with web UI, as well as no web UI at all, remote git accessed via ssh (`ssh:` git urls) with no other UI.

The issue applies to all of them. And again most teams I knew were doing this before github existed. It applies to teams using gitlab or bitbucket or other in similar ways now too.

I still don't thinkit makes sense to blame github specifically , as I believe you are doing, for the way most teams choose to use git -- since before github existed, and still now using a variety of software choices in addition to github.

It's not specifically github, but I believe this wrong mental model was greatly popularized by it. Until GitHub rose to fame a project had reasonable chances to pick mercurial, or sometimes SVN; today the default is git on GitHub. That is the issue: when you choose a tool not because it's the best at what you want to do, but for other (very good) reasons: it's popular so you'll find help easily, more people will interact with you, etc...

So, no, GitHub didn't create this, but it made it default

> Obviously you can't undo that.

I'd wager I press the "undo" button in gmail at least 3/4 times per week

This only works because you can configure gmail to send email on a timer instead of immediately.

Also, may I kindly suggest that you aren't putting enough thought into your emails? That may be fine for single-recipient emails (depending on your environment), but when your email is received by many people it's an unkind act that shows disregard for the recipient's time and attention.

> but when your email is received by many people it's an unkind act that shows disregard for the recipient's time and attention.

most of my e-mail are just chat conversations with a title

That's because you have a 30s timer that doesn't actually send anything until it counts to 0.

After it actually sends the e-mail, there's no going back.

And for like a decade this was only available under Gmail Labs, and without it enabled gmail would send immediately and couldn't "undo" the send.

sure, but that 30s timer is an incredibly useful feature, when you misclick, when your cat walks on your keyboard, when you remember that you forgot $RANDOM_THING, etc etc

Sure, and git could have an option to add a timer as well, but I don't think people notice git push mistakes as quickly as they do with e-mails.

If you were before the github, you would not expect an ability to un-push changes. If you were doing development back then, you are likely familiar with "ftp" (or maybe "sftp") and using it to upload files. Or maybe with CSV or SVN.

Question from the blogpost: "I git pushed and I want to undo it"

Compare with: "I uploaded the file on the server with FTP, overriding previous version. How do I undo this?"

Or: "I did 'svn commit', how do I undo this?"

Or: "I have sent an email. How do I un-send it?"

I am not sure where does the original author's expectation that you can undo any action comes from. "thrwyoilarticle" seems to says this is because they started from "github" interface which has nice friendly UI which warns you about actions which cannot be undone. This sounds reasonable to me.

Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is.

With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the corrected tree with just the one corrected patch.

The objects are still there even with a rebase flow, it's not as if github does a gc every push?

It's not about the object database, it's about what you see with git log.

History flow will show all the meandering around forever, but rebase will remove it and just put the most recent version of the commit on top of the tree. Ie, your log looks like you pushed just the perfect patches each time, every time, and the junk is gone.

I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history should be a statement of intent and treated as a first-class citizen, or even the primary output. Pushing a branch with threshing is like sending an email with visible backspaces.

Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.

I have been using git for years, and have never rebased once. I'm kind of scared to try, perhaps irrationally. Rebasing seems to change commit relationships in a way that seems like it may be difficult to untangle if it later differs with someone else's clone.

I would also like the ability to see a nicely curated set of changes. This mostly exists in the diff tabs of a pull request. If this were to be a first-class feature in git, it seems appropriate to be in some layer other than commits, but alas, that doesn't exist.

Rebasing one tree on another is a pretty specific thing, you may not need to do it very often.

But casually manipulating the order of, or combining or filtering, patches near the top of the tree is something else. There are tools for this, eg

https://github.com/stacked-git/stgit

Rebase is best done before you share commits with anyone.

I routinely do an interactive one before PRs to clean things up.

Is there a reliable way to know whether any of the involved commits have been pushed anywhere? I would probably usually know off the top of my head, but not always.

Check your local branch and the associated remote branch in your git log.

If the remote branch is an ancestor of your local branch, you have some commits that haven't been pushed yet and you can "play" with them.

If the remote branch and the local branch point to the same, you can't rebase without potentially impacting someone else.

If the remote branch and the local branch have diverged, it's already too late.

> I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent.

If it's rebased then you're not reading the history; you're reading an artificial modification of what actually happened, performed by someone (possibly past-you) who thinks they know more about what you're trying to do.

I don't rebase precisely because I want to read the history to see what happened.

Mercurial has solved this quite elegantly. The Evolve extension is basically standard functionality and all changesets (commits) have a state: secret, draft, public. You can share the changesets and you can "prune" them, which basically tells the world that if they have a changeset with that hash to delete it.

> Is a Github problem, not a git problem.

Git (the software) consists of two things. the git client (on your machine) and the git server (wherever you push).

It is most definitely not a GitHub problem if you pushed your changes to a local network git server, for example.

It's entirely possible to run git standalone, there's no hard requirement for there to be a git server that you push to.

Yep; plus changes can even be pushed/pulled between local directories (e.g. using 'file://'). Rewriting history can break all sorts of things.

> If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire.

Whether you realize it or not, that's gatekeeping. The point of UX is to remove artificial gates. When people apologize for the gates instead of fixing them, well... That's tantamount to threatening people's livelihood. It's a lot easier to do that when you don't think of it that way, and it probably shouldn't be easy. "I understand it, you shouldn't work here if you don't" is literally, "Fuck you, I got mine," with different words.

> about git being hard. But there is a shortage of effective, popular competitors

There is only so much oxygen in a room. There is not space for a million solutions to every problem, and once the Hype Train has left the station all you have left is to make the fiction true, or try to accelerate the Trough of Disillusionment so we can get on with fixing the problems instead of deflecting.

And I say this as the only person on a large team fit to do anything approaching surgery on screwed up git repositories. There is frequently a degree of turf protection via "he's a bastard, but he's our bastard". No, he's just a bastard. I don't claim any responsibility, I just have to interact with him.

Not just Github. Having any GUI be your first interaction with Git is a disaster. Right now the only way to learn Git is via book or man page, and command line. All the decent GUIs I have used assume you already know Git. They are great and powerful, but they don't help at all with the onboarding process. If you know of one, please share. I had to stop using GUIs completely and learn with Git command line. Then the GUIs made sense.

Rather than a problem with GitHub, I think it's more just a problem of dominance. Git was originally designed for a work environment where people weren't on the same network, or any network at all when making code edits. At the same time, everyone wanted a copy of the history that they could change themselves to mirror their work. So we needed a tool which could be distributed, not require a regular network connection, and still enable people to share changes and view the entire history of a project.

Git was primarily adopted because it solved those issues which were important ones at the time, people discovering git needed those tools and when discovering git would naturally come across and understand the trade-offs. IE: "I can't easily undo a change once it's on someone else's machine, instead I would need to issue a new change reverting it. But that's ok, because it means I can do as I like on my machine without screwing up the history for other people and only send a patch of specific changes when I'm ready."

The issue people now face is git has become so popular, because of those initial reasons, and we're dealing with a new set of problems which git never cared about.

"Project X is in a git repository, and I want to contribute a change".

This is a fundamentally different problem to the original problems git tried to solve. We're now in this weird space where most people using git are only using it because: it's what they already know, or the project they want to work on already uses git.

Requests like "I just pushed a change and didn't really want to" don't make much sense and don't matter much in the original use cases. Now many git projects use centralised hosting and a lot of people don't really care about git, just getting their work done, we now have this UX issue. The UX issue isn't a result of poor design or implementation in git, it's due to the motivations of users being fundamentally different now.

Sure you could argue that git should change or be easier, but then it would stop serving the original purpose. If people want a centralised source control with the ability to easily retract changes and have branches be the same across all nodes then really they just don't need what Git sets out to solve.

The issue is git is now dominant, and that forces people to use it even if they don't have the problems that git is really attempting to solve. That means they're stuck in a place of using a tool so they can collaborate, without getting any of the benefits of it. That's enough to drive anyone insane! It's like pushing a boat across land to get to another village when a boat is really to get to another continent, but no one makes cars because everyone's already boats.

We don't need "better" UX for git, we just need people to know about all the options, and part of that may include encouraging some people to choose more centralised options when it's a better fit for them.

It's worth highlighting that the Linux kernel was doing open source development using Git and email long before GitHub was created.

Reply on news.ycombinator.com