9 ms·

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fuc

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve. Git is hard for idiots imo, and there are a lot of us

levosmetalo 7y ago
> Git is hard for idiots imo, and there are a lot of us Then let the idiots end up screwing their own local repo, instead of doing some magic and making it easy to screw up upstream or someone else repo.
vvillena 7y ago
> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want to learn more about git in a practical way, there's an awesome book called Git Recipes.
- brigandish 7y ago
  That is not easier than "blat and re-clone" so I think you're proving their point.
  - munmaek 7y ago
    If you’re just going to blat and reclone, then you may as well use a folder system instead of git. I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.
    - mannykannot 7y ago
      I did not read brigandish's comment as advocacy of 'blat and reclone', I took it to be a comment on git's awkwardness. I have considerable sympathy for the RTFM reply, but I do not think it is the last word that shuts down any question of usability. What seems clear to me is that there are a lot of people using git who probably should not be. In many cases, they do not have a choice, but I also suspect that many of the organizations that have chosen git do not have the issues that it is optimized for.
    - brigandish 7y ago
      > I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes. In my opinion, solving problems and making improvements involves reducing complexity, not defending it. Many people, including myself, have read the Git docs and learnt about the underlying data structures etc etc and still we can make the claim that it could be better, in numerous ways. Calling everyone feckless won't invalidate that.
      - munmaek 7y ago
        > we can make the claim that it could be better I’m not disputing this. Of course git isn’t perfect. What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.
        antris 7y ago
        > What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?
        munmaek 7y ago
        Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a problem, good! But using tools is part of the profession; they have learning curves. Most issues with git are PEBKAC issues because people refuse to spend 10 minutes of their life reading about a tool they may use for hundreds or thousands of hours. I wouldn’t want to cater to those kinds of people.
  - vvillena 7y ago
    Recloning means redoing your work on top of a potentially different codebase. The approach I described is how you "blat and reclone" using git instead of the filesystem, and it has the clear advantage of keeping everything in the same repo. You can then mix all the code together in whatever way you prefer. Git is a very flexible tool that allows for individual local workflows independent of how teams collaborate. Finding a personal workflow that works for you is a little investment that pays huge dividends for a long time. Git is a 15 year old tool that is expected to live for 10-30 years more at the very least. I encourage everyone to learn enough Git to not be afraid of it.
- raducu 7y ago
  Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?
  - vvillena 7y ago
    "git branch -d" doesn't remove a branch if that means losing track of some local commits. "-D" doesn't check that. The "git branch" commands only operate on your local repo, they don't push any changes to remote repos and they don't pull commits from anywhere.
  - WorldMaker 7y ago
    `-D` doesn't involve the remote at all (unless you are using something like the intentional remote:branch syntax which this example isn't). It is a force delete in that if there were commits locally in that branch and only in that branch it should still delete that branch. It should be unlikely you need that force because the first step was to branch everything as is, so it is safer to just use `-d`, but if the intention is to "blat" it from orbit anyway, `-D` is that.
- Ntrails 7y ago
  Deleting master is a thing that would _actually_ never have occurred to me! A neat trick That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)
  - vvillena 7y ago
    The git "master" branch is just an example of 'convention over configuration': some commands use it as the default argument, just like "origin" is the default remote name. Nothing in git is special or sacred! :)
DaiPlusPlus 7y ago
I wish git had a “metahistory” feature to allow everyone to undo anything. A `git revert` isn’t of any help when you’ve already merged and pushed.
- jerf 7y ago
  It's called "git reflog": https://www.edureka.co/blog/git-reflog/ https://www.edureka.co/blog/git-reflog/ Though you do have to have committed. One of the things I hammer on in my tutorials for work is that if you get confused in git, make sure you commit. If you commit, you can take your problem to the other engineers and we can almost certainly get you straightened away. Fail to commit, though, and you really may lose something. Also, metapoint about git: While I won't deny its UI carries along some dubious decisions carried over from the very first design, in 2020, basically, if you thing "Git really ought to be able to do [this sensible thing]", it can. It has that characteristic that open source software that has been worked on by a ton of contributors has, which is that almost anything you could want to do was probably encountered by somebody else and solved five years ago. It just may take some searching around to figure out what that is. (And on the flip side, when you read the git man pages and are going "Why the hell is that in there?", the answer may well be "a problem that you're going to have in six months".)
  - jorvi 7y ago
    > make sure you commit This is not absolute gospel. If you screw up a rebase and commit, whatever you removed in the rebase is simply gone.
    - vrsfvwae5tbh 7y ago
      Does this not show up in the reflog?
    - chousuke 7y ago
      How would it be gone? You can't rebase onto a dirty working directory so you can't blow away uncommitted changes accidentally and any state prior to and during the rebase is always recoverable via the reflog. It takes trying to do anything that's not easily recoverable as long as you commit before you start messing around and don't rm -rf .git.
eyegor 7y ago
Harkening back to my early days of git, I have a rough guess as to what you can do to fix that. If all you want is remote master, git stash git checkout master git stash git fetch origin git reset --hard origin/master and maybe a 'git rm -r --cached .' in case you have staged files you didn't intend to which stash failed to drop.
wyoung2 7y ago
> Git is hard for idiots imo, and there are a lot of us Yes, thus https://xkcd.com/1597/ https://xkcd.com/1597/ I find myself saying "git reset --hard origin/" and such with disturbing frequency. Both are examples of "I give up; it's faster to start over." This is not what I want in a DVCS.
rjsw 7y ago
The workflow that I have found works best is to just not change anything myself, I let other people do all the work. This way I can be sure that I won't get merge conflicts that I can't fix.
munmaek 7y ago
With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If something happens once, it happens. If something happens multiple times then it means you’re not evaluating why it occurred in the first place and learning from it. No tool in the world can solve this problem because it’s not a problem with the tool, rather the user. Git is really not so hard, but it requires a little reading.
- metabagel 7y ago
  Git isn’t something which you can generally be successful using in a shallow way. Most developers will need to devote significant time and energy to mastering it. There really needs to be a better layer on top of it in order to make it easier for developers to figure out how to do what they want to do. Some of the commands and switches don’t seem to be orthogonal and/or intuitive.
  - wasdfff 7y ago
    A lot of people get by just staging and pushing/pulling commits, myself included. That’s 3 commands, 4 if you count git status. You do not need to dig deep to get a lot of use out of git as a basic remote sync.
  - munmaek 7y ago
    Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly. > significant time and energy All someone needs is to read through https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/, and learn a few commands. Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how git works. You know, on how the tool that you’re using works. Why are people so allergic to spending even a modicum of time on learning a tool that massively simplifies their life and makes their work possible? Do plumbers complain about having to read manuals for the equipment that they use? Electricians? As programmers our tools are easier to learn and use, yet we complain about having to any work at all. Why even be a programmer? If reading about git is so hard, what about the rest of the field that doesn’t even have documentation? How about we don’t make tools that cater to the lowest common denominator, in this case people who basically can’t be assed to do anything? RTFM.
deleted 7y ago
[deleted]
wasdfff 7y ago
Git push/pull -f Then write a little merge message and you are good to go.
etripe 7y ago
You could always do: git reflog to see when you last checked out master, then: git reset <commit hash> --soft to reset to the commits at that point (but keep your files the same) git add . && git stash save to stash your changes (not 100% sure you actually need the "git add ." part) git pull in master and then finally: git stash pop and commit again as needed.

levosmetalo 7y ago

> Git is hard for idiots imo, and there are a lot of us Then let the idiots end up screwing their own local repo, instead of doing some magic and making it easy to screw up upstream or someone else repo.

vvillena 7y ago

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want to learn more about git in a practical way, there's an awesome book called Git Recipes.

brigandish 7y ago
That is not easier than "blat and re-clone" so I think you're proving their point.
- munmaek 7y ago
  If you’re just going to blat and reclone, then you may as well use a folder system instead of git. I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.
  - mannykannot 7y ago
    I did not read brigandish's comment as advocacy of 'blat and reclone', I took it to be a comment on git's awkwardness. I have considerable sympathy for the RTFM reply, but I do not think it is the last word that shuts down any question of usability. What seems clear to me is that there are a lot of people using git who probably should not be. In many cases, they do not have a choice, but I also suspect that many of the organizations that have chosen git do not have the issues that it is optimized for.
  - brigandish 7y ago
    > I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes. In my opinion, solving problems and making improvements involves reducing complexity, not defending it. Many people, including myself, have read the Git docs and learnt about the underlying data structures etc etc and still we can make the claim that it could be better, in numerous ways. Calling everyone feckless won't invalidate that.
    - munmaek 7y ago
      > we can make the claim that it could be better I’m not disputing this. Of course git isn’t perfect. What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.
      - antris 7y ago
        > What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?
        munmaek 7y ago
        Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a problem, good! But using tools is part of the profession; they have learning curves. Most issues with git are PEBKAC issues because people refuse to spend 10 minutes of their life reading about a tool they may use for hundreds or thousands of hours. I wouldn’t want to cater to those kinds of people.
- vvillena 7y ago
  Recloning means redoing your work on top of a potentially different codebase. The approach I described is how you "blat and reclone" using git instead of the filesystem, and it has the clear advantage of keeping everything in the same repo. You can then mix all the code together in whatever way you prefer. Git is a very flexible tool that allows for individual local workflows independent of how teams collaborate. Finding a personal workflow that works for you is a little investment that pays huge dividends for a long time. Git is a 15 year old tool that is expected to live for 10-30 years more at the very least. I encourage everyone to learn enough Git to not be afraid of it.
raducu 7y ago
Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?
- vvillena 7y ago
  "git branch -d" doesn't remove a branch if that means losing track of some local commits. "-D" doesn't check that. The "git branch" commands only operate on your local repo, they don't push any changes to remote repos and they don't pull commits from anywhere.
- WorldMaker 7y ago
  `-D` doesn't involve the remote at all (unless you are using something like the intentional remote:branch syntax which this example isn't). It is a force delete in that if there were commits locally in that branch and only in that branch it should still delete that branch. It should be unlikely you need that force because the first step was to branch everything as is, so it is safer to just use `-d`, but if the intention is to "blat" it from orbit anyway, `-D` is that.
Ntrails 7y ago
Deleting master is a thing that would _actually_ never have occurred to me! A neat trick That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)
- vvillena 7y ago
  The git "master" branch is just an example of 'convention over configuration': some commands use it as the default argument, just like "origin" is the default remote name. Nothing in git is special or sacred! :)

DaiPlusPlus 7y ago

I wish git had a “metahistory” feature to allow everyone to undo anything. A `git revert` isn’t of any help when you’ve already merged and pushed.

jerf 7y ago
It's called "git reflog": https://www.edureka.co/blog/git-reflog/ https://www.edureka.co/blog/git-reflog/ Though you do have to have committed. One of the things I hammer on in my tutorials for work is that if you get confused in git, make sure you commit. If you commit, you can take your problem to the other engineers and we can almost certainly get you straightened away. Fail to commit, though, and you really may lose something. Also, metapoint about git: While I won't deny its UI carries along some dubious decisions carried over from the very first design, in 2020, basically, if you thing "Git really ought to be able to do [this sensible thing]", it can. It has that characteristic that open source software that has been worked on by a ton of contributors has, which is that almost anything you could want to do was probably encountered by somebody else and solved five years ago. It just may take some searching around to figure out what that is. (And on the flip side, when you read the git man pages and are going "Why the hell is that in there?", the answer may well be "a problem that you're going to have in six months".)
- jorvi 7y ago
  > make sure you commit This is not absolute gospel. If you screw up a rebase and commit, whatever you removed in the rebase is simply gone.
  - vrsfvwae5tbh 7y ago
    Does this not show up in the reflog?
  - chousuke 7y ago
    How would it be gone? You can't rebase onto a dirty working directory so you can't blow away uncommitted changes accidentally and any state prior to and during the rebase is always recoverable via the reflog. It takes trying to do anything that's not easily recoverable as long as you commit before you start messing around and don't rm -rf .git.

eyegor 7y ago

Harkening back to my early days of git, I have a rough guess as to what you can do to fix that. If all you want is remote master, git stash git checkout master git stash git fetch origin git reset --hard origin/master and maybe a 'git rm -r --cached .' in case you have staged files you didn't intend to which stash failed to drop.

wyoung2 7y ago

> Git is hard for idiots imo, and there are a lot of us Yes, thus https://xkcd.com/1597/ https://xkcd.com/1597/ I find myself saying "git reset --hard origin/" and such with disturbing frequency. Both are examples of "I give up; it's faster to start over." This is not what I want in a DVCS.

rjsw 7y ago

The workflow that I have found works best is to just not change anything myself, I let other people do all the work. This way I can be sure that I won't get merge conflicts that I can't fix.

munmaek 7y ago

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If something happens once, it happens. If something happens multiple times then it means you’re not evaluating why it occurred in the first place and learning from it. No tool in the world can solve this problem because it’s not a problem with the tool, rather the user. Git is really not so hard, but it requires a little reading.

metabagel 7y ago
Git isn’t something which you can generally be successful using in a shallow way. Most developers will need to devote significant time and energy to mastering it. There really needs to be a better layer on top of it in order to make it easier for developers to figure out how to do what they want to do. Some of the commands and switches don’t seem to be orthogonal and/or intuitive.
- wasdfff 7y ago
  A lot of people get by just staging and pushing/pulling commits, myself included. That’s 3 commands, 4 if you count git status. You do not need to dig deep to get a lot of use out of git as a basic remote sync.
- munmaek 7y ago
  Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly. > significant time and energy All someone needs is to read through https://rogerdudler.github.io/git-guide/ https://rogerdudler.github.io/git-guide/, and learn a few commands. Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how git works. You know, on how the tool that you’re using works. Why are people so allergic to spending even a modicum of time on learning a tool that massively simplifies their life and makes their work possible? Do plumbers complain about having to read manuals for the equipment that they use? Electricians? As programmers our tools are easier to learn and use, yet we complain about having to any work at all. Why even be a programmer? If reading about git is so hard, what about the rest of the field that doesn’t even have documentation? How about we don’t make tools that cater to the lowest common denominator, in this case people who basically can’t be assed to do anything? RTFM.

deleted 7y ago

[deleted]

wasdfff 7y ago

Git push/pull -f Then write a little merge message and you are good to go.

etripe 7y ago

You could always do: git reflog to see when you last checked out master, then: git reset <commit hash> --soft to reset to the commits at that point (but keep your files the same) git add . && git stash save to stash your changes (not 100% sure you actually need the "git add ." part) git pull in master and then finally: git stash pop and commit again as needed.