10 ms·

Common Git Problems and How to Fix Them

228 points by mzehrer 8y ago

nerdponx 8y ago
I'm sorry, I hate "recipe style" Git articles. Understanding reset and checkout is not hard if you understand the underlying data model. If you don't understand te data model, it's all black magic. Interestingly, I feel the same way about actual recipe books for cooking. It's one thing to keep around as a reference. But if you don't know what a bay leaf tastes like and what it does to a dish, you won't learn anything from someone telling you to use it in a particular recipe.
- ollysb 8y ago
  I would love to read a cooking book which talked about the effect of ingredients and process. Anybody know if one exists? edit: well this one looks interesting https://www.amazon.com/Ingredient-Unveiling-Essential-Elements-Food/dp/0062385356 https://www.amazon.com/Ingredient-Unveiling-Essential-Elemen...
  - LoveSubs 8y ago
    Nathan Myhrvold Edit: And many others too
  - nerdponx 8y ago
    I have a few I can personally recommend: - How to Cook Everything by Mark Bittman (also How to Cook Everything Vegetarian) - Ratio by Michael Ruhlman - The Food Lab by J. Kenji Lopez-Alt - Salt, Fat, Acid, Heat by Samin Nosrat
    - RBerenguel 8y ago
      I can also vouch for Ratio, and in general any book by Ruhlman I've read has been excellent (give Egg a go)
  - pjmorris 8y ago
    Have a look at 'On Food and Cooking', Harold McGee. It isn't a cookbook, but McGee talks extensively about ingredients, process, and their interactions.
  - Analemma_ 8y ago
    Cook's Illustrated magazine doesn't get so far as explaining the chemistry, but they do document the lengthy trial, error and tuning process to get their recipes right, as well as what decisions they made and why.
  - nothrabannosir 8y ago
    Take a look at Chef John’s recipes on YouTube. He knows his stuff, and he makes sure to explain the thought behind the process. It’s illuminating and entertaining. https://youtube.com/user/foodwishes https://youtube.com/user/foodwishes
  - aequitas 8y ago
    I would recommend https://www.cookingforgeeks.com https://www.cookingforgeeks.com
  - wool_gather 8y ago
    I'll strongly second the Cook's Illustrated recommendation. If you want to know the reasons behind the recipes, there's no better place to start. I've used things I've learned from their articles many, many times to help with other recipes. And here's some books that spend at least as much time talking about how to cook as they do giving lists of ingredients. _The Zuni Cafe Cookbook_ by Judy Rodgers _Cooking by Hand_ by Paul Bertolli The French Laundry book by Thomas Keller is worth a read. If you're into charcuterie, someone else mentioned Michael Ruhlman; his book _Charcuterie_ with chef Bryan Polcyn is excellent. _The River Cottage Meat Cookbook_ is also good. If you want to go deep into ingredients, _The Elements of Taste_ by Gray Kunz and Peter Kaminsky (and _The Flavor Bible_ by Karen Page and Andrew Dornenberg (I haven't personally read that one all the way through, though)). And you can always just pick up a culinary school textbook.
    - nerdponx 8y ago
      The Flavor Bible is more of an ingredient reference. It's also very Western- and Northern- (as in the hemisphere) centric.
  - ahartmetz 8y ago
    I found such a thing in a textbook belonging to a friend's mother who went to some kind of household school in the 70s or so. It was a revelation. When I later wrote some teaching material, I realized that there are two bad kinds of educational texts: Cookbooks and math textbooks. One is a simplistic series of steps without explanation, the other is a facts dump with no motivation, context or intuition. Getting back to git, its documentation manages to combine the disadvantages of both styles: it is a disjointed cookbook where steps are explained in confusing technical terms that only make sense if you already know the theory, which isn't coherently explained.
- ken 8y ago
  I don't understand this fad that programmers should know only first principles, and shun checklists in favor of deriving everything from scratch every time. I know how my car works but I still pull out the service manual when I need to change an air filter. Nothing under the hood is 'black magic' but seeing the procedure written out saves me a ton of time. And: git commands are hard, even if you understand the underlying data model. (I've only been using it for 8 or 9 years. Maybe I'm just too dumb?) Understanding the data model won't help me remember that the "--amend" flag is how I edit the commit message (though I could probably build it myself from reset + commit, if I really wanted to), or what folder I should put global pre-commit hooks in.
  - nerdponx 8y ago
    I don't understand this fad that programmers should know only first principles, and shun checklists in favor of deriving everything from scratch every time. I know how my car works but I still pull out the service manual when I need to change an air filter. Nothing under the hood is 'black magic' but seeing the procedure written out saves me a ton of time. The problem is that the explanations of the commands are wrong. Reset does not undo a commit. It moves HEAD and updates the work tree. I have no problem with cheat sheets and quick references. Memorizing the commandline interface is not important. Use a cheat sheet. Handwaving over what the commands you are running actually do is asking for trouble. Edit: I was witness to a similar debate on IRC the other day. Someone insisted but you can't learn Python without understanding the underlying data model of strings in C. IMO that is ridiculous because the abstraction in Python is close to airtight; you just about never need to think about the implementation of strings when using strings. Git, on the other hand, frequently exposes implementation details to the user. Casual users are likely to run into edge cases that don't understand. You basically can't resolve rebase conflicts effectively if you don't know what "ours" and "theirs" means. The man pages are indecipherable if you don't know what blobs and trees are. You don't need to teach people that stuff on day one, when they first learn about pull, add, commit, etc. But you had better teach them soon. I see no reason why a discussion of rebase couldn't at least casually explain how it's implemented: "check out base branch, cherry-pick commits from rebased branch", is that so hard? If they don't understand what a common ancestor is, how are they expected to know when to use --onto?
levi_n 8y ago
I found the list helpful, with just about everything I would expect in a list such as this. If I could make one suggestion: I found it to be quite annoying to have to click through to a two-line gist for every single one command. Having those commands be in the article itself would be considerably easier to read.
- doodhwala 8y ago
  Linking to this comment instead of the actual link you want so that the right person gets credit :) https://news.ycombinator.com/item?id=17634075 https://news.ycombinator.com/item?id=17634075
  - extralego 8y ago
    Can’t tell if joking.
0x0 8y ago
Don't use push --force, use push --force-with-lease. Then you avoid accidentally undoing unexpected new commits on the remote.
- stygiansonic 8y ago
  More information on this option, as well as caveats: https://developer.atlassian.com/blog/2015/04/force-with-lease/ https://developer.atlassian.com/blog/2015/04/force-with-leas...
- fcarraldo 8y ago
  Better yet, don’t use push —force at all unless you specifically intend to undo commits on the remote. Resolve conflicts locally and never force push to a shared branch.
  - jeremyjh 8y ago
    This forces you to merge master into your shared topic branches instead of rebasing them on master, which makes the history harder to follow.
    - u801e 8y ago
      You can always run something like: git diff origin/your-branch..your-branch to check whether you have made any unintentional changes to the code. For the commits themselves, you can do something like: git log origin/master..origin/your-branch and git log origin/master..your-branch to see if the commits differ. You can use the -p switch on the git log commands to see if the diffs have changed. If you do this before pushing up to the remote, then it's much easier to see what you're going to change before you run git push -f.
    - pjc50 8y ago
      Could you explain this and why it requires --force? (One of the features of git that I struggle to understand isn't a deal-killer for its adoption is the lack of repo access control; if you want this you have to implement it manually through PRs)
cdubzzz 8y ago
Another reference site that has come in handy for me for quick reminders, and has a very memorable name -- http://ohshitgit.com/ http://ohshitgit.com/
- hyperpape 8y ago
  More comprehensive (enough so that I haven't read every entry): https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules
Hello71 8y ago
In addition to what nerdponx said about recipe style articles being poor, there are some moderate issues with this article: 1. it doesn't clearly say that git checkout with a path is irreversible. 2. it says that git reset --hard is irreversible, which is not correct. (see 3.) 3. it doesn't mention one of the most powerful git features for fixing mistakes, the reflog. 4. git remove is not a git command. 5. gitingore is not a git file. 6. git-amend is not a git command. 7. It doesn't adequately explain why force-pushing causes problems. It looks like clicking through to the gists was such a pain that even the author didn't proofread them.
- nerdponx 8y ago
  Oh god, I missed this one: git checkout with a path is irreversible Not only is it a reversible, but it is destructive. It will overwrite untracked changes and even untracked files, without so much as a warning. I personally consider this a critical bug in Git, but apparently the mailing list denizens do not agree with me.
  - mikro2nd 8y ago
    And this is exactly the sort of behaviour that led me to call git "The Swiss Army Chainsaw of Version Control". It can do anything, but if you wield it wrong it'll cut your leg off without hesitation. I consider this a UX failure. Give me hg anytime.
    - Hello71 8y ago
      That is, broadly speaking, not correct. The reflog makes it very difficult to permanently lose committed changes, and for the most part, commands that change the working directory are generally self-evident. git checkout is really the only common command that has this non-obvious behavior, and even then, only when checking out a path; checking out a commit will warn before overwriting working directory changes. In fact, from what I read, git is far better than mercurial in this respect, as reflog is always on, whereas the journal extension must be manually enabled.
arenaninja 8y ago
Out of all these, I wish I could use git bisect the most. Working on large codebases with large teams, the command itself is a godsend. Unfortunately a PC with Symantec Endpoint Protection makes the filesystem dog slow to the point that the one time I needed it and it should've taken about 13 steps to find where the bug was introduced, it was faster to redo the feature without accessing the previous code
- forg0t_username 8y ago
  Did you try to add your development folder to the AV's exception list?
- majewsky 8y ago
  You mean Symantec?
  - arenaninja 8y ago
    Ah yes. Fixed :)
- megaman22 8y ago
  Intrusive anti-virus products imposed by people that don't know better than to click on dodgy porn sites and download and run untrusted binaries is a great way to waste tens of thousands of dollars of developer productivity. God help you if you're doing front-end development, with deep node_modules and build processes creating and destroying files.
nottorp 8y ago
So why do i have to open 10 more tabs to see the actual commands? Or am I supposed to blindly run them without knowing what they are?
majewsky 8y ago
I'm seeing only github gist URLs instead of code snippets. What became of progressive enhancement?
- StavrosK 8y ago
  Nothing. They actually are links, not embedded gists.
ecthiender 8y ago
Why aren't code snippets part of the article? Why are they hosted somewhere else? Especially when they are 2-3 line snippets.
- lilbobbytables 8y ago
  I'm wondering if they meant to embed them.
  - dguo 8y ago
    It looks like the author used Medium's import tool[1] but didn't change the gist links to embeds. The source for the import is a gist itself[2], which just has the raw links. [1]: https://help.medium.com/hc/en-us/articles/214550207-Import-post https://help.medium.com/hc/en-us/articles/214550207-Import-p... [2]: https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb22809018 https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb2...
- sus_007 8y ago
  > Originally published at gist.github.com Maybe because the article was originally a gist[0] itself. [0] https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb22809018 https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb2...
  - alangpierce 8y ago
    That gist links back to the actual original article, which shows code inline: https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd https://www.codementor.io/citizen428/git-tutorial-10-common-...
    - extralego 8y ago
      This should be the posted article. A lot of useful stuff here but not readable until I found this.
StavrosK 8y ago
function fuckgit rm -rf /tmp/fuckgit/ git clone --no-checkout (git config --get remote.origin.url) /tmp/fuckgit/ rm -rf .git/ mv /tmp/fuckgit/.git . rm -rf /tmp/fuckgit/ end
- jwilk 8y ago
  What shell is this? You use /tmp in an insecure way. Please use "mktemp -d" for creating temporary directories.
  - StavrosK 8y ago
    It's fish. What's insecure about the way I'm using it?
    - jwilk 8y ago
      /tmp is world-writable. Any local user could create /tmp/fuckgit and stuff it with malicous code.
      - teddyh 8y ago
        Or create /tmp/fuckgit as a symbolic link beforehand, pointing to a directory which will be deleted by the first command in your function.
      - StavrosK 8y ago
        I see, thank you.
magoon 8y ago
I advocate: git add -p for interactive staging. It’ll present each hunk of code with a y/n prompt. This is a good habit to prevent committing any debug code or stray marks.
- acemarke 8y ago
  That's one of the reasons why I've always preferred a GUI for most of my day-to-day operations. It's a lot easier to click "Add Hunk", or CTRL-click a couple lines and click "Unstage Lines", then it is to go through the CLI options for dozens of hunks. Similarly, SourceTree's interactive rebase UI is great, and when I briefly played with Tower's latest beta, they made it as simple as drag-and-drop for individual commits. On the flip side, it's a lot easier to do "git add -u" or "git add src/some/folder" for those use cases.
  - crtasm 8y ago
    'tig' is a TUI for git, once you learn the shortcuts it's easy to stage specific lines/hunks.
- shocks 8y ago
  git checkout -p and git reset -p work too :)
- u801e 8y ago
  I've gone further with this when staging parts of the diff while viewing the output of git diff in vim. You can visually highlight the part of the diff along with the diff header lines and run :'<,'>!git-apply --cached - git apply is one of the git "plumbing" commands that can be used to apply patches to the working directory or the git index.
alangpierce 8y ago
I think the most powerful tool for fixing mistakes is "git reflog". It doesn't fix everything, but it works very well as long as you view git with the right mental model: a git repo is an ever-growing tree of immutable commits, with branches and tags pointing to the most interesting ones. As long as code has ever made it into that tree (by being in any commit at any time), it's recoverable, and reflog lets you trace your steps back to any point in the past on that tree. Supposedly-destructive operations like amend and rebase actually just build the tree at a different point and move branches to other places in the tree, but (pretty much) nothing in the tree is ever destroyed. For the actually-destructive git commands like checkout and reset, another tool that I'd highly recommend is a "local history" feature in your editor. JetBrains IDEs do this by default, and other editors have plugins for it. It automatically records changes as you make them so you can go back to previous versions of any file. Usually git is enough to save me, but I've also had plenty of times where I make some mistake outside of git commit history and am saved by digging through local history.
- magoon 8y ago
  Local History in my IDE has saved me many times!
- Stratoscope 8y ago
  SmartGit has a brilliant implementation of the reflog. The Git command line reflog is just a list of hashes and messages. If you're not sure which of those commits is the one you want, it's a fairly laborious process to dig through them. What if you have several commits with the same message, as will happen if you've rebased or amended any commits? In SmartGit, you simply click the Recyclable Commits checkbox in the Log view, and now everything in the reflog shows up in the log tree, just like any other commit. You can see immediately the parent of each reflog commit, and to see what you changed, just click one of them as you would any other commit in the log. SmartGit shows the differences immediately. Same thing for stashes. After all, stashes are really just commits by another name. Click the Stashes checkbox and they show up in the log too. SmartGit is full of features like this where something cumbersome on the command line is straightforward and easy. I've used it for years and recommend it highly. https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/
davidgerard 8y ago
Mods - please link the original, which has the code fragments inline: https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd https://www.codementor.io/citizen428/git-tutorial-10-common-...
throw7 8y ago
incredibly annoying how the examples are links to another site. had to stop at the 3rd example.
michaelmrose 8y ago
Can the main article link to https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd https://www.codementor.io/citizen428/git-tutorial-10-common-... which is vastly more readable.
- dewiz 8y ago
  Oh thanks, those snippet links make it really hard to read the post otherwise
- andybak 8y ago
  Mods?
- apple4ever 8y ago
  Thank you, that’s so much better
Groxx 8y ago
As much as I like rerere, I have had it result in silently[1] producing the wrong end result. Especially since I merge / rebase frequently, and end up recording lots of small conflict resolutions. Always always always check non-clean merges by hand or you'll eventually be surprised. And sometimes I just resolved it incorrectly once, and now it always does it wrong. Is there a way to make rerere forget a resolution? [1]: relatively speaking. it doesn't fail / pause the operation, so it's "silent", even though it prints out that it applied a conflict-fix.
microtherion 8y ago
Was I the only one who was expecting something along THOSE lines? https://i.pinimg.com/originals/4d/ca/1c/4dca1ce93db819647f2f87fb92769561.jpg https://i.pinimg.com/originals/4d/ca/1c/4dca1ce93db819647f2f...
paulddraper 8y ago
Need "missing blob" (corrupted git repo). That problem is a depressing one and not uncommon [1] [1] https://stackoverflow.com/q/18678853/1212596 https://stackoverflow.com/q/18678853/1212596
Tomis02 8y ago
Can someone explain to me the fascination for git, despite the constant stream of "how to fix [insert various git issues]" articles showing it's very difficult to use, at least compared to the alternatives? Most people's work streams only need something as simple as hg, which would also save them a lot of time and hassle. My personal impression is that it's a fashion thing (people think it's cool to waste a lot of time on git, because git is cool and fixing git problems feels like real work, because you're using your keyboard and all that), but maybe someone has a different perspective.

228 points by mzehrer 8y ago

I'm sorry, I hate "recipe style" Git articles. Understanding reset and checkout is not hard if you understand the underlying data model. If you don't understand te data model, it's all black magic. Interestingly, I feel the same way about actual recipe books for cooking. It's one thing to keep around as a reference. But if you don't know what a bay leaf tastes like and what it does to a dish, you won't learn anything from someone telling you to use it in a particular recipe.

ollysb 8y ago
I would love to read a cooking book which talked about the effect of ingredients and process. Anybody know if one exists? edit: well this one looks interesting https://www.amazon.com/Ingredient-Unveiling-Essential-Elements-Food/dp/0062385356 https://www.amazon.com/Ingredient-Unveiling-Essential-Elemen...
- LoveSubs 8y ago
  Nathan Myhrvold Edit: And many others too
- nerdponx 8y ago
  I have a few I can personally recommend: - How to Cook Everything by Mark Bittman (also How to Cook Everything Vegetarian) - Ratio by Michael Ruhlman - The Food Lab by J. Kenji Lopez-Alt - Salt, Fat, Acid, Heat by Samin Nosrat
  - RBerenguel 8y ago
    I can also vouch for Ratio, and in general any book by Ruhlman I've read has been excellent (give Egg a go)
- pjmorris 8y ago
  Have a look at 'On Food and Cooking', Harold McGee. It isn't a cookbook, but McGee talks extensively about ingredients, process, and their interactions.
- Analemma_ 8y ago
  Cook's Illustrated magazine doesn't get so far as explaining the chemistry, but they do document the lengthy trial, error and tuning process to get their recipes right, as well as what decisions they made and why.
- nothrabannosir 8y ago
  Take a look at Chef John’s recipes on YouTube. He knows his stuff, and he makes sure to explain the thought behind the process. It’s illuminating and entertaining. https://youtube.com/user/foodwishes https://youtube.com/user/foodwishes
- aequitas 8y ago
  I would recommend https://www.cookingforgeeks.com https://www.cookingforgeeks.com
- wool_gather 8y ago
  I'll strongly second the Cook's Illustrated recommendation. If you want to know the reasons behind the recipes, there's no better place to start. I've used things I've learned from their articles many, many times to help with other recipes. And here's some books that spend at least as much time talking about how to cook as they do giving lists of ingredients. _The Zuni Cafe Cookbook_ by Judy Rodgers _Cooking by Hand_ by Paul Bertolli The French Laundry book by Thomas Keller is worth a read. If you're into charcuterie, someone else mentioned Michael Ruhlman; his book _Charcuterie_ with chef Bryan Polcyn is excellent. _The River Cottage Meat Cookbook_ is also good. If you want to go deep into ingredients, _The Elements of Taste_ by Gray Kunz and Peter Kaminsky (and _The Flavor Bible_ by Karen Page and Andrew Dornenberg (I haven't personally read that one all the way through, though)). And you can always just pick up a culinary school textbook.
  - nerdponx 8y ago
    The Flavor Bible is more of an ingredient reference. It's also very Western- and Northern- (as in the hemisphere) centric.
- ahartmetz 8y ago
  I found such a thing in a textbook belonging to a friend's mother who went to some kind of household school in the 70s or so. It was a revelation. When I later wrote some teaching material, I realized that there are two bad kinds of educational texts: Cookbooks and math textbooks. One is a simplistic series of steps without explanation, the other is a facts dump with no motivation, context or intuition. Getting back to git, its documentation manages to combine the disadvantages of both styles: it is a disjointed cookbook where steps are explained in confusing technical terms that only make sense if you already know the theory, which isn't coherently explained.
ken 8y ago
I don't understand this fad that programmers should know only first principles, and shun checklists in favor of deriving everything from scratch every time. I know how my car works but I still pull out the service manual when I need to change an air filter. Nothing under the hood is 'black magic' but seeing the procedure written out saves me a ton of time. And: git commands are hard, even if you understand the underlying data model. (I've only been using it for 8 or 9 years. Maybe I'm just too dumb?) Understanding the data model won't help me remember that the "--amend" flag is how I edit the commit message (though I could probably build it myself from reset + commit, if I really wanted to), or what folder I should put global pre-commit hooks in.
- nerdponx 8y ago
  I don't understand this fad that programmers should know only first principles, and shun checklists in favor of deriving everything from scratch every time. I know how my car works but I still pull out the service manual when I need to change an air filter. Nothing under the hood is 'black magic' but seeing the procedure written out saves me a ton of time. The problem is that the explanations of the commands are wrong. Reset does not undo a commit. It moves HEAD and updates the work tree. I have no problem with cheat sheets and quick references. Memorizing the commandline interface is not important. Use a cheat sheet. Handwaving over what the commands you are running actually do is asking for trouble. Edit: I was witness to a similar debate on IRC the other day. Someone insisted but you can't learn Python without understanding the underlying data model of strings in C. IMO that is ridiculous because the abstraction in Python is close to airtight; you just about never need to think about the implementation of strings when using strings. Git, on the other hand, frequently exposes implementation details to the user. Casual users are likely to run into edge cases that don't understand. You basically can't resolve rebase conflicts effectively if you don't know what "ours" and "theirs" means. The man pages are indecipherable if you don't know what blobs and trees are. You don't need to teach people that stuff on day one, when they first learn about pull, add, commit, etc. But you had better teach them soon. I see no reason why a discussion of rebase couldn't at least casually explain how it's implemented: "check out base branch, cherry-pick commits from rebased branch", is that so hard? If they don't understand what a common ancestor is, how are they expected to know when to use --onto?

levi_n 8y ago

I found the list helpful, with just about everything I would expect in a list such as this. If I could make one suggestion: I found it to be quite annoying to have to click through to a two-line gist for every single one command. Having those commands be in the article itself would be considerably easier to read.

doodhwala 8y ago
Linking to this comment instead of the actual link you want so that the right person gets credit :) https://news.ycombinator.com/item?id=17634075 https://news.ycombinator.com/item?id=17634075
- extralego 8y ago
  Can’t tell if joking.

0x0 8y ago

Don't use push --force, use push --force-with-lease. Then you avoid accidentally undoing unexpected new commits on the remote.

stygiansonic 8y ago
More information on this option, as well as caveats: https://developer.atlassian.com/blog/2015/04/force-with-lease/ https://developer.atlassian.com/blog/2015/04/force-with-leas...
fcarraldo 8y ago
Better yet, don’t use push —force at all unless you specifically intend to undo commits on the remote. Resolve conflicts locally and never force push to a shared branch.
- jeremyjh 8y ago
  This forces you to merge master into your shared topic branches instead of rebasing them on master, which makes the history harder to follow.
  - u801e 8y ago
    You can always run something like: git diff origin/your-branch..your-branch to check whether you have made any unintentional changes to the code. For the commits themselves, you can do something like: git log origin/master..origin/your-branch and git log origin/master..your-branch to see if the commits differ. You can use the -p switch on the git log commands to see if the diffs have changed. If you do this before pushing up to the remote, then it's much easier to see what you're going to change before you run git push -f.
  - pjc50 8y ago
    Could you explain this and why it requires --force? (One of the features of git that I struggle to understand isn't a deal-killer for its adoption is the lack of repo access control; if you want this you have to implement it manually through PRs)

cdubzzz 8y ago

Another reference site that has come in handy for me for quick reminders, and has a very memorable name -- http://ohshitgit.com/ http://ohshitgit.com/

hyperpape 8y ago
More comprehensive (enough so that I haven't read every entry): https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules

Hello71 8y ago

In addition to what nerdponx said about recipe style articles being poor, there are some moderate issues with this article: 1. it doesn't clearly say that git checkout with a path is irreversible. 2. it says that git reset --hard is irreversible, which is not correct. (see 3.) 3. it doesn't mention one of the most powerful git features for fixing mistakes, the reflog. 4. git remove is not a git command. 5. gitingore is not a git file. 6. git-amend is not a git command. 7. It doesn't adequately explain why force-pushing causes problems. It looks like clicking through to the gists was such a pain that even the author didn't proofread them.

nerdponx 8y ago
Oh god, I missed this one: git checkout with a path is irreversible Not only is it a reversible, but it is destructive. It will overwrite untracked changes and even untracked files, without so much as a warning. I personally consider this a critical bug in Git, but apparently the mailing list denizens do not agree with me.
- mikro2nd 8y ago
  And this is exactly the sort of behaviour that led me to call git "The Swiss Army Chainsaw of Version Control". It can do anything, but if you wield it wrong it'll cut your leg off without hesitation. I consider this a UX failure. Give me hg anytime.
  - Hello71 8y ago
    That is, broadly speaking, not correct. The reflog makes it very difficult to permanently lose committed changes, and for the most part, commands that change the working directory are generally self-evident. git checkout is really the only common command that has this non-obvious behavior, and even then, only when checking out a path; checking out a commit will warn before overwriting working directory changes. In fact, from what I read, git is far better than mercurial in this respect, as reflog is always on, whereas the journal extension must be manually enabled.

arenaninja 8y ago

Out of all these, I wish I could use git bisect the most. Working on large codebases with large teams, the command itself is a godsend. Unfortunately a PC with Symantec Endpoint Protection makes the filesystem dog slow to the point that the one time I needed it and it should've taken about 13 steps to find where the bug was introduced, it was faster to redo the feature without accessing the previous code

forg0t_username 8y ago
Did you try to add your development folder to the AV's exception list?
majewsky 8y ago
You mean Symantec?
- arenaninja 8y ago
  Ah yes. Fixed :)
megaman22 8y ago
Intrusive anti-virus products imposed by people that don't know better than to click on dodgy porn sites and download and run untrusted binaries is a great way to waste tens of thousands of dollars of developer productivity. God help you if you're doing front-end development, with deep node_modules and build processes creating and destroying files.

nottorp 8y ago

So why do i have to open 10 more tabs to see the actual commands? Or am I supposed to blindly run them without knowing what they are?

majewsky 8y ago

I'm seeing only github gist URLs instead of code snippets. What became of progressive enhancement?

StavrosK 8y ago
Nothing. They actually are links, not embedded gists.

ecthiender 8y ago

Why aren't code snippets part of the article? Why are they hosted somewhere else? Especially when they are 2-3 line snippets.

lilbobbytables 8y ago
I'm wondering if they meant to embed them.
- dguo 8y ago
  It looks like the author used Medium's import tool[1] but didn't change the gist links to embeds. The source for the import is a gist itself[2], which just has the raw links. [1]: https://help.medium.com/hc/en-us/articles/214550207-Import-post https://help.medium.com/hc/en-us/articles/214550207-Import-p... [2]: https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb22809018 https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb2...
sus_007 8y ago
> Originally published at gist.github.com Maybe because the article was originally a gist[0] itself. [0] https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb22809018 https://gist.github.com/citizen428/16fb925fcca59ddfb652c7cb2...
- alangpierce 8y ago
  That gist links back to the actual original article, which shows code inline: https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd https://www.codementor.io/citizen428/git-tutorial-10-common-...
  - extralego 8y ago
    This should be the posted article. A lot of useful stuff here but not readable until I found this.

StavrosK 8y ago

function fuckgit rm -rf /tmp/fuckgit/ git clone --no-checkout (git config --get remote.origin.url) /tmp/fuckgit/ rm -rf .git/ mv /tmp/fuckgit/.git . rm -rf /tmp/fuckgit/ end

jwilk 8y ago
What shell is this? You use /tmp in an insecure way. Please use "mktemp -d" for creating temporary directories.
- StavrosK 8y ago
  It's fish. What's insecure about the way I'm using it?
  - jwilk 8y ago
    /tmp is world-writable. Any local user could create /tmp/fuckgit and stuff it with malicous code.
    - teddyh 8y ago
      Or create /tmp/fuckgit as a symbolic link beforehand, pointing to a directory which will be deleted by the first command in your function.
    - StavrosK 8y ago
      I see, thank you.

magoon 8y ago

I advocate: git add -p for interactive staging. It’ll present each hunk of code with a y/n prompt. This is a good habit to prevent committing any debug code or stray marks.

acemarke 8y ago
That's one of the reasons why I've always preferred a GUI for most of my day-to-day operations. It's a lot easier to click "Add Hunk", or CTRL-click a couple lines and click "Unstage Lines", then it is to go through the CLI options for dozens of hunks. Similarly, SourceTree's interactive rebase UI is great, and when I briefly played with Tower's latest beta, they made it as simple as drag-and-drop for individual commits. On the flip side, it's a lot easier to do "git add -u" or "git add src/some/folder" for those use cases.
- crtasm 8y ago
  'tig' is a TUI for git, once you learn the shortcuts it's easy to stage specific lines/hunks.
shocks 8y ago
git checkout -p and git reset -p work too :)
u801e 8y ago
I've gone further with this when staging parts of the diff while viewing the output of git diff in vim. You can visually highlight the part of the diff along with the diff header lines and run :'<,'>!git-apply --cached - git apply is one of the git "plumbing" commands that can be used to apply patches to the working directory or the git index.

alangpierce 8y ago

I think the most powerful tool for fixing mistakes is "git reflog". It doesn't fix everything, but it works very well as long as you view git with the right mental model: a git repo is an ever-growing tree of immutable commits, with branches and tags pointing to the most interesting ones. As long as code has ever made it into that tree (by being in any commit at any time), it's recoverable, and reflog lets you trace your steps back to any point in the past on that tree. Supposedly-destructive operations like amend and rebase actually just build the tree at a different point and move branches to other places in the tree, but (pretty much) nothing in the tree is ever destroyed. For the actually-destructive git commands like checkout and reset, another tool that I'd highly recommend is a "local history" feature in your editor. JetBrains IDEs do this by default, and other editors have plugins for it. It automatically records changes as you make them so you can go back to previous versions of any file. Usually git is enough to save me, but I've also had plenty of times where I make some mistake outside of git commit history and am saved by digging through local history.

magoon 8y ago
Local History in my IDE has saved me many times!
Stratoscope 8y ago
SmartGit has a brilliant implementation of the reflog. The Git command line reflog is just a list of hashes and messages. If you're not sure which of those commits is the one you want, it's a fairly laborious process to dig through them. What if you have several commits with the same message, as will happen if you've rebased or amended any commits? In SmartGit, you simply click the Recyclable Commits checkbox in the Log view, and now everything in the reflog shows up in the log tree, just like any other commit. You can see immediately the parent of each reflog commit, and to see what you changed, just click one of them as you would any other commit in the log. SmartGit shows the differences immediately. Same thing for stashes. After all, stashes are really just commits by another name. Click the Stashes checkbox and they show up in the log too. SmartGit is full of features like this where something cumbersome on the command line is straightforward and easy. I've used it for years and recommend it highly. https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/

davidgerard 8y ago

Mods - please link the original, which has the code fragments inline: https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd https://www.codementor.io/citizen428/git-tutorial-10-common-...

throw7 8y ago

incredibly annoying how the examples are links to another site. had to stop at the 3rd example.

michaelmrose 8y ago

Can the main article link to https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd https://www.codementor.io/citizen428/git-tutorial-10-common-... which is vastly more readable.

dewiz 8y ago
Oh thanks, those snippet links make it really hard to read the post otherwise
andybak 8y ago
Mods?
apple4ever 8y ago
Thank you, that’s so much better

Groxx 8y ago

As much as I like rerere, I have had it result in silently[1] producing the wrong end result. Especially since I merge / rebase frequently, and end up recording lots of small conflict resolutions. Always always always check non-clean merges by hand or you'll eventually be surprised. And sometimes I just resolved it incorrectly once, and now it always does it wrong. Is there a way to make rerere forget a resolution? [1]: relatively speaking. it doesn't fail / pause the operation, so it's "silent", even though it prints out that it applied a conflict-fix.

microtherion 8y ago

Was I the only one who was expecting something along THOSE lines? https://i.pinimg.com/originals/4d/ca/1c/4dca1ce93db819647f2f87fb92769561.jpg https://i.pinimg.com/originals/4d/ca/1c/4dca1ce93db819647f2f...

paulddraper 8y ago

Need "missing blob" (corrupted git repo). That problem is a depressing one and not uncommon [1] [1] https://stackoverflow.com/q/18678853/1212596 https://stackoverflow.com/q/18678853/1212596

Tomis02 8y ago

Can someone explain to me the fascination for git, despite the constant stream of "how to fix [insert various git issues]" articles showing it's very difficult to use, at least compared to the alternatives? Most people's work streams only need something as simple as hg, which would also save them a lot of time and hassle. My personal impression is that it's a fashion thing (people think it's cool to waste a lot of time on git, because git is cool and fixing git problems feels like real work, because you're using your keyboard and all that), but maybe someone has a different perspective.