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

291–300 of 352 posts

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

#291

Post by falsedan »

noufalibrahim wrote: post #12

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…

> this path of treating git as "spell X solves problem Y" will always break down

I agree completely! Anytime you give a list of 'run this command', I think you've actually written a CLI tool in the wrong language (English instead of a programming language).

At work, we want to increase dev's confidence with git in the next few months. We're making sure to separate out 'Technical' knowledge (what do steps do I perform to recover a deleted branch) from 'Conceptual' knowledge (why would it be a good/bad idea to delete a branch, how branches are intended to be used, understanding what git thinks a branch is, etc.). The former go into git aliases or CLI swiss army knife tool, the latter into training videos and workshops.

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

#292

Post by witty_username »

jlebar wrote: post #283
witty_username wrote: post #270

Earlier quoted context omitted.

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

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

Sorry, the speedup was very great so it almost seemed like something else was causing it. Thanks for the benchmarks.

> 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.

That's true; I'm lazy.

Actually, I was thinking more of the disk cache of loading hg, not the repo (Python programs tend to have a great speedup through the disk cache).

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

#293

Post by falsedan »

mcv wrote: post #47
noufalibrahim wrote: post #12

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…

I think the biggest problem people have with git is that you can't and shouldn't want to change shared history, and yet git provides some tools that suggest that maybe you can. It's better to accept history as it is, and fix the problem with reverts, cherry-picking and new commits. History won't be as pretty or clean, but it will reflect what actually happened, which is what history is, after all. The biggest trick t…

> I think the biggest problem people have with git is that you can't and shouldn't want to change shared history, and yet git provides some tools that suggest that maybe you can.

Funny, I think the biggest problem is people who refuse to understand the caveats of rewriting shared history and spread FUD about it.

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

#294

Post by ThrustVectoring »

A somewhat lesser known git trick that's pretty much a strict improvement - use `--force-with-lease` for force pushing instead of `--force`.

What this does is check what's on the remote branch and compare it with what you think is on the remote branch, and only do the force if they're the same thing. So if someone pushes a commit, the force push errors out instead of silently overwriting it.

Basically every single time you want to force push, you probably should be doing a `--force-with-lease` instead. I can't think of a situation where you'd want to silently lose commits you don't know about rather than get an error.

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

#295

Post by leejo »

sergiosgc wrote: post #251
leejo wrote: post #43

Earlier quoted context omitted.

> Actually the easiest thing is simply not to care about how your log looks. You need to expand on this because i don't quite understand what you mean, are you talking about "fix typo" commits or are we getting to the level of just committing away until things work and then not cleaning up the work later on? The linked article doesn't cover rebasing or squashing commits, which can be pretty powerful when used correct…

Develop on feature branches, merge with master only when the feature is done. Always merge with --no-ff. Then, when reviewing history, on the master branch you can use either "git log" or "git log --first-parent master". The first log is the complete log, with exploratory development, mistakes, backtracks and such. The second is the clean log people keep rewriting history to obtain. You get your cake and you can eat…

This is pretty much the reason i don't understand people who don't want merge commits (the use case for rebase in the video is modifying commits in a feature branch BTW, not merging to master). You can bend git logs to your will with the various options so there's no problem in being as verbose as possible in commit messages and the concept of a "linear history" is a moot point because, no matter how messy your history actual is, there's a command line option to clear it up.

Be verbose in your commit messages and don't worry about merge commits, it will pay dividends later.

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

#296

Post by duaneb »

jlebar wrote: post #262
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.

$ 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.

Well, you can just use the silver searcher with both. This is not a great argument for a better DVCS.

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

#297

Post by junke »

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?

Magit

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

#298

Post by web007 »

noufalibrahim wrote: post #16
wfunction wrote: post #15

Surprised there was nothing on messed-up merges or rebases. They're some of the worst to get out of when you're not totally comfortable with git yet.

And reflog. It sort of like revision control of your branches and commands. Very useful to extricate oneself from various situations.

+100 for reflog. Even for the stupidest cross-merges I've broken reflog has been my savior.

https://git-scm.com/docs/git-reflog

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

#299

Post by srigi »

Doing mumbo-jumbo between branches with `git stash` is way to hell. Don't do it, you lose data. This fucker will unstash changes until first conflict, then it stop and present you with >>>>>>ID which nobody understand. Well I understand it, but never know which is which (theirs/ours label don't help here). You try to undo everything, but then you're fucked - all unstashed changes are removed from stash while conflicts are still there. You must be very careful now not to lose changes. You won't succeed!

That is I believe `git stash` should be removed from git as evil data loosing feature, not needed. Instead just make an alias `git save ` which saves your temporary work to the branch:

`save = !sh -c 'export PREV=$(git symbolic-ref HEAD|cut -d/ -f3-) && git checkout -b "$1" && git commit -am "$1" && git checkout "$PREV"' -`

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

#300

Post by joshuahutt »

srigi wrote: post #299

Doing mumbo-jumbo between branches with `git stash` is way to hell. Don't do it, you lose data. This fucker will unstash changes until first conflict, then it stop and present you with >>>>>>ID which nobody understand. Well I understand it, but never know which is which (theirs/ours label don't help here). You try to undo everything, but then you're fucked - all unstashed changes are removed from stash while conflict…

You can use `git stash apply` to apply the stashed changes without removing them from the stash.
Post reply on HN