The undo button for @blakeyrat's favorite software




  • FoxDev

    How big is that onebox‽



  • It's the entire post, but without the formatting. Because Discourse.


  • FoxDev

    @ben_lubar said:

    git rebase

    If you're rewriting history with rebase make sure you know what the hell you are doing and that there isn't any other viable option. because rebase is as dangerous as it is powerful.

    misuse it through ignorance or malice and you will quickly find your repo is FUBAR'd



  • What's happening: git revert will create a new commit that's the
    opposite (or inverse) of the given SHA. If the old commit is "matter",
    the new commit is "anti-matter"—anything removed in the old commit will
    be added in the new commit and anything added in the old commit will be
    removed in the new commit.

    This is Git's safest, most basic "undo" scenario, because it doesn't
    alter history—so you can now git push the new "inverse" commit to undo
    your mistaken commit.

    Unless there's a commit inbetween, why can't undo just simply do UNDO like every other concept out there. If I want to undo, I don't care about the history of undo. Just delete the last delta, and done.

    Undo "local" changes

    Scenario: The cat walked across the keyboard and somehow saved the
    changes, then crashed the editor. You haven't committed those changes,
    though. You want to undo everything in that file—just go back to the way
    it looked in the last commit.

    Undo with: git checkout -- <bad filename>

    What's happening: git checkout alters files in the working directory to a
    state previously known to Git. You could provide a branch name or
    specific SHA you want to go back to or, by default, Git will assume you
    want to checkout HEAD, the last commit on the currently-checked-out
    branch.

    Keep in mind: any changes you "undo" this way are really gone. They were
    never committed, so Git can't help us recover them later. Be sure you
    know what you're throwing away here!

    Like this. But it only works locally.

    You made some commits, did a git reset --hard to "undo" those changes
    (see above), and then realized: you want those changes back!

    sigh



  • You can still do those with pushed changes, but if anyone's pulled them, it'll mess them up when they try to update again.



  • Hmm.... this is why your files should be as atomic as code.

    You'll want to isolate changes to separate files anyway, so you don't have to merge.

    I know, it should work like discourse, and change stuff as your working on it, with notifications, because anything is ok as long as you send a notification.

    Bableep: Your harddrive is mirrored to a harddrive that is in the process of being reformatted. Have a nice day!


  • :belt_onion:

    It's a nice option for bringing your offline branch up to date. Never rebase pushed commits though, because that will lead to much unhappiness and gnashing of teeth.


  • FoxDev

    @sloosecannon said:

    It's a nice option for bringing your offline branch up to date.

    yes, still dangerous if you're not careful.

    @sloosecannon said:

    Never rebase pushed commits

    #QFT



  • @xaade said:

    Unless there's a commit inbetween, why can't undo just simply do UNDO like every other concept out there. If I want to undo, I don't care about the history of undo. Just delete the last delta, and done.

    Seriously.

    I can see the argument about race-conditions-- maybe someone else slipped in a commit before you hit "revert to X". So maybe it makes sense. Maybe?

    What I'd really like to do is merge commits together with a new message after I push them to the issue's branch but before I merge them into Master. Which seems such a fucking obvious thing to want to do I'm still, after all this time, flabbergasted that Git offers no way of solving that problem. Not even a poorly-designed shitty way with no GUI.


  • :belt_onion:

    @blakeyrat said:

    Which seems such a fucking obvious thing to want to do

    Not if you're using Git like you're supposed to...

    @blakeyrat said:

    Not even a poorly-designed shitty way with no GUI

    Also, false, you just need to not push before you merge them. Because if you do, you break things.



  • If you want to merge changes into one commit and change the message before pushing them (which is what you just described), you want an interactive rebase.


  • :belt_onion:

    But he pushes those commits. So * rebase is BAD

    If he changed his workflow to only push after he rebased, that would work though



  • No, he doesn't push them to the main branch until he's done. He pushes them to a different branch. He's not deleting anything.


  • :belt_onion:

    Doesn't matter. If you push things, then do a rebase, you're rewriting history on the server. Which is a very bad thing to do...



  • But he's not rewriting history - he's making a new commit using existing changes.


  • :belt_onion:

    @ben_lubar said:

    But he's not rewriting history - he's making a new commit using existing changes.

    I believe interactive rebase deletes the commits it uses. But even if it doesn't, that wouldn't solve his problem because he wants to delete the commits... Which you can do. As long as you don't push them first


  • FoxDev

    @ben_lubar said:

    you want an interactive rebase.

    actually what it really sounds like what he wants is something like github's Pull Requests.

    Fork the repo. do a bunch of work, then package it up in one giant PR and push it to host repo.

    which is totally doable outside of github too, it's just github automates all the work for you.



  • @ben_lubar said:

    If you want to merge changes into one commit and change the message before pushing them (which is what you just described), you want an interactive rebase.

    Goddammit, Ben, we already went over all this.

    No, what I want to do, there is no safe way to do. There's a way with the potential to cause disaster and absolutely zero UI support.



  • @accalia said:

    actually what it really sounds like what he wants is something like github's Pull Requests.

    Something similar (we're using Atlassian Stash, which has PRs), but the problem I have now is the only level of detail I have is:

    1. wrap the entire feature in a single PR with a single commit or

    2. merge the PR with all its commits, including the useless trash ones like "check in to switch branches" or "going home for the night putting code on the server"


  • FoxDev

    well if you have PRs and are willing to put up with a little annoyance there's option 3)

    1. wrap subfeature checkins into a series of PRs from DevFork to StagingFork as per #1, when everything is done and ready to move into MasterRepo perform #2 from StagingFork

    it's a little more work, and requires two forks, but it does give you the level of granularity you want without polouting MasterRepo with intermediate checkin messages



  • Or Git could let me push code to the server without making a commit. You know, like duh duh duuuh TFS does.


  • FoxDev

    @blakeyrat said:

    Or Git could let me push code to the server without making a commit

    -shrug- yeah that would be a nice feature. have you suggested it to the Git project as an enhancement request? server based stashes would be nice to have.

    @blakeyrat said:

    You know, like duh duh duuuh TFS does

    yes, but unlike TFS, Git is free. and for a VCS it's actually pretty good. There are things it doesn't do well, and there are things it really does well.

    Seriously though, i think option 1 you listed or option 3 i suggested are both quite workable and will work around your core issue, the preferable solution requires a git plugin or a change to core git which is, assuming the change request is approved, at least a couple of years out from reaching stable.

    They sucks and are both a less than optimal flow, but they will get the job done.



  • @accalia said:

    -shrug- yeah that would be a nice feature. have you suggested it to the Git project as an enhancement request?

    HahahahahahHAHAHAHAHAHAHAHHAHAHAHAHahhaHHAHAHAHAhahHAHAHAHAH

    Yeah, I want to download a 1994-esque IRC client just so I can be told how wrong I'm doing everything. I'm sure that would be a great experience.

    Why the fuck should I have to put in a feature request for something its competitors already have? I mean, isn't it obvious they should implement handy and proven features from competitors? Do I have to help them get the toilet seat in the right position before they pee, too?

    @accalia said:

    yes, but unlike TFS, Git is free.

    @accalia said:

    and for a VCS it's actually pretty good

    It's not entirely ass. It seems to operate pretty reliably when it's not throwing mysterious errors for no reason. Except it's slow as fuck when handling lots of files, and it always has to handle lots of files because there's no way to checkout only part of a repo.

    @accalia said:

    There are things it doesn't do well, and there are things it really does well.

    There is nothing it "really does well".


  • FoxDev

    @blakeyrat said:

    Why the fuck should I have to put in a feature request for something its competitors already have?

    because if you don't the feature won't get added?

    @blakeyrat said:

    https://www.visualstudio.com/products/what-is-visual-studio-online-vs

    good luck convincing most companies that are in the windows stack that letting anyone (including microsoft) host their proprietary code in off site servers is a good idea. You still gotta pay to run TFS locally.

    and i'm willing to bet there's a fairly small repo size limit for the free version too.

    still it's good to know there's a free version.

    @blakeyrat said:

    It's not entirely ass.

    High praise indeed considering the source. although i can't say i disagree with the sentiment. TFS and git are the only two VCS that i've worked with that didn't earn the "this belongs in the outhouse" badge.

    Not that i like either one . I just tend to go for Git because i do so little C# in my personal projects that using TFS is more hassle than it's worth.


  • ♿ (Parody)

    @blakeyrat said:

    Or Git could let me push code to the server without making a commit. You know, like duh duh duuuh TFS does.

    Or you could set up a nightly backup process like a normal person.



  • @accalia said:

    good luck convincing most companies that are in the windows stack that letting anyone (including microsoft) host their proprietary code in off site servers is a good idea.

    That's GitHub's business model and they seem to do ok.

    @accalia said:

    TFS and git are the only two VCS that i've worked with that didn't earn the "this belongs in the outhouse" badge.

    Oh no doubt. It's an area where all the solutions are ass.

    @boomzilla said:

    Or you could set up a nightly backup process like a normal person.

    It's a laptop. It's usually hibernating in a bag at night.


  • ♿ (Parody)

    You're right. It's crazypants to attempt to back up from a laptop.



  • What exactly is @blakeyrat doing where the cost of replacing a laptop is less than the cost of redoing a bit of code that he started 10 minutes before leaving for the day and didn't get to finish?



  • Why is the cost of the laptop relevant?



  • I assume you wouldn't need to use your "backup" if your laptop didn't explode.



  • Yeah, but why does the cost of the laptop figure in? It has to be replaced anyway regardless of if the code is lost due to lack of backup or not so it shouldn't factor into the evaluation of end-of-day check ins.



  • He doesn't need to back up the data at the end of each day because the stuff he didn't start 10 minutes before leaving is already backed up on the server.



  • @ben_lubar said:

    He doesn't need to back up the data at the end of each day because the stuff he didn't start 10 minutes before leaving is already backed up on the server.

    What if it's 4 days worth of work? Why do you keep saying 10 minutes, as if I only check-in 4 lines of code at a time?



  • Why do you have 4 days of work without any progress that you can commit?



  • Because the Federal rules on health savings accounts are really fucking complicated? Because super-atomic robots are forcing me to at gunpoint?

    What does it matter why? Point is, Git is ass.



  • If you need to commit, go ahead, but don't push the commits if you don't want them to be part of the main repo.



  • Then a car accident, bam, and all my work is lost. We've gone over this again and again.

    I'm not packing up the laptop without the source being secure on the server. This isn't a strange or weird or unusual thing to do, Git just doesn't support it.


  • FoxDev

    Trying to dredge a load of stuff from memory, so I'll probably get some of the details wrong, but it's my understanding that the core issue is that features are not to be committed piecemeal; a feature is either committed to main in one go, or it's not committed at all. Personally, I think that arrangement is asinine, but if that's what @blakeyrat has to work with because of regulation and/or company policy, then he doesn't really have a choice in the matter.

    Really, the problem is @blakeyrat's company is trying to use a DVCS like a CVCS. If they used something like TFS, then shelvesets are on the server, and everything's fine; his code would be on the server without being committed to main, as is the requirement. But because it's git (and the same would happen with hg and other DVCS), shelvesets are local, and AFAIK, there's no way to replicate them on the server without committing the changes and pushing. And as soon as you commit, it's not a shelveset.

    What's really needed is an ability to push shelvesets to a central repo. Which git doesn't support. So you're left with either:

    1. Copy the files to a backup location on the server
    2. Set up a clone repo on the server to commit to, then do the incantations to collapse the commits into a single commit that is pushed to main, whether that's by PR or other means

    Which is basically choosing between a giant douche and a turd sandwich.



  • ben@australium:~/blakeyrat$ git init
    Initialized empty Git repository in /home/ben/blakeyrat/.git/
    ben@australium:~/blakeyrat$ echo "some code" > file1.txt
    ben@australium:~/blakeyrat$ echo "some code" >> file1.txt
    ben@australium:~/blakeyrat$ echo "some code" >> file1.txt
    ben@australium:~/blakeyrat$ cat file1.txt 
    some code
    some code
    some code
    ben@australium:~/blakeyrat$ git add file1.txt 
    ben@australium:~/blakeyrat$ git commit -m 'commit a file I guess'
    [master (root-commit) 6d6511c] commit a file I guess
     1 file changed, 3 insertions(+)
     create mode 100644 file1.txt
    ben@australium:~/blakeyrat$ git checkout -b feature-whatever
    Switched to a new branch 'feature-whatever'
    ben@australium:~/blakeyrat$ echo "I like cheese" >> file1.txt 
    ben@australium:~/blakeyrat$ git add file1.txt 
    ben@australium:~/blakeyrat$ git commit -m 'going home or whatever'
    [feature-whatever 07ac524] going home or whatever
     1 file changed, 1 insertion(+)
    ben@australium:~/blakeyrat$ echo "8 people are @blakeyrat" >> file1.txt 
    ben@australium:~/blakeyrat$ git add file1.txt 
    ben@australium:~/blakeyrat$ git commit -m 'wow, work is hard'
    [feature-whatever e69fb0c] wow, work is hard
     1 file changed, 1 insertion(+)
    ben@australium:~/blakeyrat$ git checkout master
    Switched to branch 'master'
    ben@australium:~/blakeyrat$ git merge --squash feature-whatever
    Updating 6d6511c..e69fb0c
    Fast-forward
    Squash commit -- not updating HEAD
     file1.txt | 2 ++
     1 file changed, 2 insertions(+)
    ben@australium:~/blakeyrat$ git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
    
            modified:   file1.txt
    
    ben@australium:~/blakeyrat$ git commit -m 'some feature or whatever'
    [master 3e3571b] some feature or whatever
     1 file changed, 2 insertions(+)
    ben@australium:~/blakeyrat$ git log --graph
    * commit 3e3571be45e69adc0f1a3d0ac95974c9c3edec70
    | Author: Ben Lubar <ben.lubar@gmail.com>
    | Date:   Mon Jun 8 16:33:31 2015 -0500
    | 
    |     some feature or whatever
    |  
    * commit 6d6511c8c7a513b5ab0740d3f92e3cc2ff93fcec
      Author: Ben Lubar <ben.lubar@gmail.com>
      Date:   Mon Jun 8 16:13:01 2015 -0500
      
          commit a file I guess
    


  • Ok I can't read that bullshit and I don't care.



  • Summary:

    • Make a bunch of changes on some-branch-name
    • Switch back to the main branch
    • git merge --squash some-branch-name
    • commit with a descriptive message


  • Ok; now where's the GUI for it?



  • Is typing git merge --squash some-branch-name too much effort?



  • Yup.



  • Should I make a program that runs that for you and has a GUI with a single unlabeled button?



  • You can do whatever you like, I'm not your dictator.


  • Discourse touched me in a no-no place

    Props to don Quixote!


  • Discourse touched me in a no-no place

    @blakeyrat said:

    You can do whatever you like, I'm not your dictator.

    Ironically, in the Alanis Morissette sense, I am eating literally eating popcorn as I read this.


  • Winner of the 2016 Presidential Election

    IntelliJ has GUI support for both interactive rebases and squash merges. You just have to use an IDE that doesn't suck.


Log in to reply