Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

Post reply on HN
Print view View original

361–370 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#361

Post by falsedan »

lmm wrote: post #356
sirmarksalot wrote: post #328

Earlier quoted context omitted.

Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you. After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch. In a merge workflow, you have to either fail forward (fix the probl…

Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.

It’s a lot of paperwork to avoid a perfectly safe and normal git command.

Re: Oh shit, git: Getting myself out of bad situations

#362

Post by CJefferson »

mFixman wrote: post #167

Honestly, a lot of what's wrong in git is that people seem to mostly memorize or copy-paste a finite amount of commands, and when something goes wrong they are completely lost unless they can find a way to copy-paste a solution. Instead of saving a 6 command list for some use cases, why not just get used to the simple but kinda unintuitive way of how revisions and branches work? If you know that, you can solve any pr…

Quick quiz, what does 'git checkout x/y' do? I am aware of users hitting at least 3 interpretations.

Re: Oh shit, git: Getting myself out of bad situations

#363

Post by jacobsenscott »

Most oh shit git moments are a result of "advanced" git users trying to force people who just want to get shit done to "keep the history clean" with rebases. If you stick with git push, pull, and merge you really can't lose work. And any "advanced" git user knows the right git log incantation to filter out merge commits and such to make the history look clean.

Re: Oh shit, git: Getting myself out of bad situations

#364

Post by xaphod »

jsmthrowaway wrote: post #298
AlexCoventry wrote: post #81

Earlier quoted context omitted.

On the other hand, doing it is the only way you're going to learn. Just do it in a safe environment, with a snapshot of the repository.

Yep. That is the important tip, right here. $ pushd .. $ cp -a my-project my-project-before-I-did-git-surgery $ popd Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up? $ pushd .. $ rm -rf my-project $ cp -a my-project-before-I-did-git-surgery my-project $ popd Undo is a great thing, and it's also important to triple check the entire state of the re…

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git.

If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

Re: Oh shit, git: Getting myself out of bad situations

#365

Post by TomK32 »

lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

I always do `git add --patch`, it's very precise and I can edit lines before staging them. I really don't see why someone would work without it (or a GUI).

Re: Oh shit, git: Getting myself out of bad situations

#366

Post by pkamb »

lwansbrough wrote: post #42

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

In addition to better staging and committing, I love my git GUI for allowing me to easily see and work with every past commit.

Right click on any commit and I can create a new branch there, copy the SHA, do a mixed reset to that location, rebase on it, etc. SO much easier to visualize the actual tree of commits you're working with.

I'm sure some people do do all that from the command line. But every CLI coworker of mine has really only known the basics of branching and committing. The GUI unlocks the repo and all of its branches and commits as something you can play with and explore.

Re: Oh shit, git: Getting myself out of bad situations

#368

Post by keithnz »

_pmf_ wrote: post #114
emeraldd wrote: post #59

Earlier quoted context omitted.

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

I recommend SmartGit; it's not cheap, but it's really, really nice.

SmartGit is really nice.

It's also free for hobby / open source

but worth buying for commerical work, but it is pricey, and I think getting the lifelong updates is the way to go.

Re: Oh shit, git: Getting myself out of bad situations

#369

Post by jsmthrowaway »

xaphod wrote: post #364
jsmthrowaway wrote: post #298

Earlier quoted context omitted.

Yep. That is the important tip, right here. $ pushd .. $ cp -a my-project my-project-before-I-did-git-surgery $ popd Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up? $ pushd .. $ rm -rf my-project $ cp -a my-project-before-I-did-git-surgery my-project $ popd Undo is a great thing, and it's also important to triple check the entire state of the re…

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git. If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your choice to spend the next hour typing the right Git commands to get back where you wanted to be, or just back out and try again. I know which one I'd prefer.

Re: Oh shit, git: Getting myself out of bad situations

#370

Post by jsmthrowaway »

palunon wrote: post #339
jsmthrowaway wrote: post #298

Earlier quoted context omitted.

Yep. That is the important tip, right here. $ pushd .. $ cp -a my-project my-project-before-I-did-git-surgery $ popd Then relax. This is extremely important before playing with nasty Git surgical tools such as huge rebases. Borked it up? $ pushd .. $ rm -rf my-project $ cp -a my-project-before-I-did-git-surgery my-project $ popd Undo is a great thing, and it's also important to triple check the entire state of the re…

>If you're having to fix stuff with -f, you're going to run into trouble; try to avoid -f ever. I disagree. I don't have much experience using git with big teams, but at least for small team where a developer usually owns a feature branch, force pushing to the branch to take into account criticism on commits can be helpful. Of course, in that case, feature branches are considered non shared. Git own "next" branch is…

> force pushing to the branch to take into account criticism on commits can be helpful

Hm? Criticism on commits should be additive. The commit was made, response was made, and a new commit addresses the response. Rewriting history breaks a lot of things and removes context. Another approach:

1) Add commit addressing criticism.

2) Squash when merging feature in to master, which is one of the only cases where I think rewriting history is OK.

Much cleaner master history, no rewriting history (which you should never do once another checkout sees your branch, including GitHub), and a number of other benefits. If you're routinely force pushing feature branches, something is broken in your workflow, IMO.

Post reply on HN