10 ms·

+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 mi

+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.

outsomnia 6y ago
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.
- Macha 6y ago
  The objects are still there even with a rebase flow, it's not as if github does a gc every push?
  - outsomnia 6y ago
    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.
- thrwyoilarticle 6y ago
  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.
  - larzang 6y ago
    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.
    - recursive 6y ago
      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.
      - outsomnia 6y ago
        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 https://github.com/stacked-git/stgit
hvidgaard 6y ago
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.
jrochkind1 6y ago
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.
- thrwyoilarticle 6y ago
  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.
  - jrochkind1 6y ago
    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.
Lendal 6y ago
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.
wpietri 6y ago
> 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.
- beagle3 6y ago
  > 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.
- horsawlarway 6y ago
  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.
holtalanm 6y ago
> 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.
- bak3y 6y ago
  It's entirely possible to run git standalone, there's no hard requirement for there to be a git server that you push to.
  - chriswarbo 6y ago
    Yep; plus changes can even be pushed/pulled between local directories (e.g. using 'file://'). Rewriting history can break all sorts of things.
bluehatbrit 6y ago
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.
hinkley 6y ago
> 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.

outsomnia 6y ago

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.

Macha 6y ago
The objects are still there even with a rebase flow, it's not as if github does a gc every push?
- outsomnia 6y ago
  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.
thrwyoilarticle 6y ago
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.
- larzang 6y ago
  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.
  - recursive 6y ago
    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.
    - outsomnia 6y ago
      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 https://github.com/stacked-git/stgit

hvidgaard 6y ago

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.

jrochkind1 6y ago

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.

thrwyoilarticle 6y ago
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.
- jrochkind1 6y ago
  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.

Lendal 6y ago

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.

wpietri 6y ago

> 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.

beagle3 6y ago
> 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.
horsawlarway 6y ago
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.

holtalanm 6y ago

> 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.

bak3y 6y ago
It's entirely possible to run git standalone, there's no hard requirement for there to be a git server that you push to.
- chriswarbo 6y ago
  Yep; plus changes can even be pushed/pulled between local directories (e.g. using 'file://'). Rewriting history can break all sorts of things.

bluehatbrit 6y ago

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.

hinkley 6y ago

> 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.