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

281–290 of 352 posts

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

#281

Post by recursive »

dahart wrote: post #201
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 he…

If the "right" solution is more difficult, and no more effective than fucking this noise, then in what sense is it even desirable or good to use the "right" solution? How is it more right?

I think the nuclear option is pretty nice, since it solves every git problem I've ever heard of. All the "right" solutions only solve some particular slice of cases. Why should I be bothered to care?

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

#282

Post by BeetleB »

exDM69 wrote: post #253
overgard wrote: post #240

Earlier quoted context omitted.

God, it's probably billions. I love git but its user interface is borderline criminal. The sad thing is mercurial has like 95% of git's power and is waaay easier to understand, but it never took off in a big way.

> The sad thing is mercurial has like 95% of git's power and is waaay easier to understand Mercurial has a clean and simple UI, especially if you come from a SVN background. But Git's internals are simpler and the concept is much easier to understand, especially if you start looking at a handful of the most popular Mercurial extensions, some of which will be "must have" sooner or later. This is no excuse for an incon…

>But Git's internals are simpler and the concept is much easier to understand,

I'm only an occasional Git user, but am a heavy Mercurial user.

I have never needed to understand Mercurial's internals.

Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already.

From my observation over the years, people who use Git get "stuck" more often, because they are trying to leverage the extra power Git seems to provide. With Mercurial, you often can do similar powerful stuff, but they make sure you have to go through hoops to do it. As such, unsuspecting non-power users do not shoot themselves in the foot.

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

#283

Post by jlebar »

witty_username wrote: post #270
jlebar wrote: post #262

Earlier quoted context omitted.

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.

Did you run hg grep once before to keep it in the disk cache?

It seems I cannot post a performance comparison without people asking about disk caches. :)

First of all, if I just cloned the repos, they should be in disk cache. My machine has 64GB of RAM.

Second of all, if they're not in disk cache, what on earth is hg doing that it takes 16 seconds to read them all in? Eigen is not that big, and I have a fast SSD.

Third of all, you can run the tests yourself -- I gave you the exact commands to try. "I tried it and my results are X" is a much better contribution to the discussion.

Fourth of all, yes, I ran the benchmarks multiple times in a row to check whether disk cache was at play. It was not. :)

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

#284

Post by aromatt »

bjackman wrote: post #271
aromatt wrote: post #267

Earlier quoted context omitted.

Yep. I find that most of the time, the commit I want to fixup is my last one, so I don't even need the interaction. I use this script almost every day: last_commit=$(git log --oneline | head -1 | cut -d' ' -f1) git commit -a --fixup ${last_commit} GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash ${last_commit}~1

What's the difference between this and 'git commit --amend'?

I'd say my script is equivalent to `git commit --all --amend --no-edit`

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

#285

Post by jlebar »

BeetleB wrote: post #280
jlebar wrote: post #262

Earlier quoted context omitted.

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.

This is also why I prefer using C over Python. (End Sarcasm). Seriously? You're so productive that the cost of cloning a repository is a major impediment? The benefits of a cleaner interface mostly trump the benefits of speed.

> Seriously? You're so productive that the cost of cloning a repository is a major impediment?

Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.

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

#286

Post by dahart »

recursive wrote: post #281
dahart wrote: post #201

Earlier quoted context omitted.

> 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 he…

If the "right" solution is more difficult, and no more effective than fucking this noise, then in what sense is it even desirable or good to use the "right" solution? How is it more right? I think the nuclear option is pretty nice, since it solves every git problem I've ever heard of. All the "right" solutions only solve some particular slice of cases. Why should I be bothered to care?

Totally depends on the situation, but it's uncommon for nuke to be easier and more effective than fixing things using a rebase. Specifically, all of the examples in the blog post are easier to solve with the right git command than they are with a nuke & re-clone.

There's a class of bad situations that nuke will make worse and not better. Any time you have un-pushed work, you're better off figuring out how to restore it with proper git commands than by nuking your repo. Dropped stashes or screwed up merges or rebase mistakes are all things that take some unavoidable time to learn how to fix.

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

#287

Post by falsedan »

inopinatus wrote: post #170
hacksonx wrote: post #35

Earlier quoted context omitted.

I think the command we're looking for is 'rm -R name_of_directory'

Honestly, the proper command is not rm at all, because you can then have an "oh shit I forgot something" moment. I have learned (the hard way) to retain even an horribly broken repo, but shove it out of the way. Because disk is cheap, repeating work is expensive. So that example should have been: cd .. mv fucking-git-repo-dir fucking-git-repo-dir.archived.$(date +%s) git clone https://some.github.url/fucking-git-repo…

  git fetch origin master && git reset --hard origin/master
imo

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

#288

Post by busterarm »

recursive wrote: post #276
busterarm wrote: post #252

Earlier quoted context omitted.

I've worked with a guy who only uses GUI tools for Git and he's supposed to be a senior dev and doesn't know how to resolve a simple merge conflict and regularly wipes out other peoples' work with whatever he's doing with the tool. No thanks.

Anecdotally, it's even easier to wipe out other peoples' work with the CLI.

Agreed, but then it's harder to blame the tool they use instead of themselves.

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

#289

Post by BeetleB »

jlebar wrote: post #285
BeetleB wrote: post #280

Earlier quoted context omitted.

This is also why I prefer using C over Python. (End Sarcasm). Seriously? You're so productive that the cost of cloning a repository is a major impediment? The benefits of a cleaner interface mostly trump the benefits of speed.

> Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.

Ah. My mistake.

16s is not a big deal, but I'm assuming it would get much worse for larger repositories.

Personally, my searches are either:

1. Restricted to all files that end in cpp, h, py, pl, etc.

2. Explicitly exclude .hg directories.

I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters (.cpp,.h) and is usually the first item in the drop down box. Much quicker than typing out a grep command.

Still, I feel if our team used git instead of hg, we'd lose a lot more time due to people not grokking git and making mistakes than the time lost in longer searches.

My point still stands: Things like search time are not a productivity bottleneck. If all our searches were 100x faster, there would be no difference in our output.

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

#290

Post by falsedan »

dahart wrote: post #203

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.

Here's my standard recommendations:

* Learn Git Branching (gentle introduction to git's UI, with a visualization of the DAG) [0]

* Git for ages 4 and up (beginner-oriented, teaches you how to model git's internal concepts, 90m video) [1]

* Git from the bottom-up (high-level overview of git's internal data structures) [2]

* My Git Habits (sophisticated, you will have to study the man pages used to completely internalize the workflow) [3]

[0]: http://pcottle.github.io/learnGitBranching/

[1]: https://youtu.be/1ffBJ4sVUb4

[2]: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

[3]: http://blog.plover.com/prog/git-habits.html

Post reply on HN