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

Some bad Git situations and how I got myself out of them

ohshitgit.com

Post reply on HN
Print view View original

201–210 of 352 posts

Re: Some bad Git situations and how I got myself out of them

#201

Post by dahart »

lambdacomplete wrote: post #116

Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough and you should take a GOOD course about git as soon as humanly possible. Shameless plug: http://engineering.hipolabs.com/how-to-work-in-a-team-versio...

> Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough

I think that's a tad judgemental for two reasons:

1- because git is legitimately hard to learn. Personally I suspect git is unnecessarily hard to learn, that command names and the concepts and workflows I need are possible to learn and use with less effort. For many years people around me have been asking for git help because I know how to recover from lost stashes and use the reflog, etc., and yet I still have to google the magic incantations for commands I use regularly because they're impossible to remember.

2- There is actually a lot of value in being able to spin up a new repo instantly, in knowing that you can, and in practicing it often. Not unlike the move to VMs for development environments. Plus, there are definitely bad situations where a fresh git clone is the simpler way to go -- just not in this article. ;)

Anyway, I also agree with you because this blog post doesn't describe any truly bad situations, and because for years I've seen people blowing away their repos and starting over, and always thought to myself it was funny. It's a drastic action that takes more work than a rebase or reflog or whatever the problem was, and doesn't work well if you've made changes.

Re: Some bad Git situations and how I got myself out of them

#202

Post by mkj »

coldpie wrote: post #190
mkj wrote: post #147

Another option is to use Mercurial with hg-git to GitHub for network effects. I've been doing that for a while for dropbear ssh, it does hit occasional problems but is overall more pleasant than straight git.

To each his own, of course. As a Git aficionado, I find Mercurial utterly baffling. Branches are permanent and global? You have to clone the repo to make a new thing I would call a branch? "hg log" shows you things that are not in the history of your current source tree? Mind boggling. :)

I agree with you about "hg log". --follow should be the default.

s/branches/bookmarks/ and it's the same as git.

Re: Some bad Git situations and how I got myself out of them

#203

Post by dahart »

Great idea! We need more basic git workflows described in plain English.

I was expecting some actual "bad" situations based on the title, and to be fair these were bad to me once and are bad for people new to git, but I'd love to see the level 2,3,etc. version of this article.

Re: Some bad Git situations and how I got myself out of them

#204

Post by theknarf »

coldpie wrote: post #190
mkj wrote: post #147

Another option is to use Mercurial with hg-git to GitHub for network effects. I've been doing that for a while for dropbear ssh, it does hit occasional problems but is overall more pleasant than straight git.

To each his own, of course. As a Git aficionado, I find Mercurial utterly baffling. Branches are permanent and global? You have to clone the repo to make a new thing I would call a branch? "hg log" shows you things that are not in the history of your current source tree? Mind boggling. :)

What git calls branches is most similar to what Mercurial calls tags.

Re: Some bad Git situations and how I got myself out of them

#205

Post by mi100hael »

V-2 wrote: post #185
OJFord wrote: post #151

Earlier quoted context omitted.

This looks like an awesome way to learn git, and many would probably love to continue with it - but many others too would prefer to move to the CLI. I used to use a GUI for git, but now I just find them cumbersome; by their nature requiring me to switch window for less.

For commands maybe, but nothing beats a graphical history tree. It's hard for a human to imagine a complex branch history without a good visual aid

I can't think of a single time I've actually ever cared to look at anything other than a linear history or a single file's blame. I do have a 'hist' alias set up (http://blog.wittchen.biz.pl/basics-of-git/#gist16617665), but it's not something I ever actually use.

Re: Some bad Git situations and how I got myself out of them

#206

Post by phaemon »

mcv wrote: post #140
ZeroGravitas wrote: post #97

Earlier quoted context omitted.

Ah, interesting. I'd noticed this behaviour but hadn't conciously thought about it. The docs say: All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD

If they're not in upstream but they are in another branch, it's still dangerous.

I don't understand. Could you give an example?

Re: Some bad Git situations and how I got myself out of them

#207

Post by OskarS »

mungoman2 wrote: post #19
glandium wrote: post #10

> Oh shit, I accidentally committed to the wrong branch! Other ways to do it (that don't require to retype the commit message): - rebase onto the correct branch: git branch foo git reset --hard HEAD~ git rebase --onto name-of-the-correct-branch HEAD foo git checkout name-of-the-correct-branch git merge foo git branch -D foo - cherry-pick git reset --hard HEAD~ git checkout name-of-the-correct-branch git cherry-pick n…

Or use git branch -m to rename master to something else, then checkout master anew.

That's clever, I'll remember that. But don't you lose all tracking information if you do that?

Re: Some bad Git situations and how I got myself out of them

#208

Post by dahart »

mhw wrote: post #161

One of the nice workflows that's already built in to the git command line tools is this one. When you're working on a branch and realise that a commit you made a few commits back has a mistake in it: # Make correcting change git commit --all --fixup= # Continue working on branch, then at some point git rebase --interactive --autosquash The --fixup option creates commits with subjects formatted like 'fixup! previous c…

Yeah, super useful, I can second setting auto squash in the config. I was almost thinking of saying the same thing, but I realized this post is probably deliberately avoiding rebase. This workflow is advanced relative to the problems described, and you'd agree those command lines are going to look pretty intimidating to a novice, right? They were to me the first time, there's a lot to understand before they're comfortable.

Re: Some bad Git situations and how I got myself out of them

#209

Post by base698 »

eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I've seen repos completely borked because the gui kept a merging and pushing in the background. This was after spending a lot of time removing binaries from a repo and not being able to figure out how the same binaries kept ending up back on origin.

Re: Some bad Git situations and how I got myself out of them

#210

Post by cx1000 »

Im_a_throw_away wrote: post #157
eyelidlessness wrote: post #34

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I'm curious: What are the best free GUI for Git?

gitk - it's built into git, and supplements (not replaces) the command line. It does tree visualization and diffs between commits.
Post reply on HN