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

271–280 of 352 posts

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

#271

Post by bjackman »

aromatt wrote: post #267
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…

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'?

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

#272

Post by busterarm »

wyclif wrote: post #49

If you're concerned about not knowing how to do certain things with git, and understanding at a deeper level how git works, I highly recommend reading Scott Chacon's "Pro Git" book: https://progit.org/

Seconded.

Also, I think everyone should go through Neo's Git Immersion at some point early in their experience with git. It is the best crash course by far.

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

#273

Post by MattyRad »

> Bizarrely, git won't do a dif of files that have been add-ed to your staging area without this flag

Not sure what's bizarre about that. Doing so helps keep your commits clean and helps git tools (diff, git-gutter, etc) by ignoring things you've already stated are complete.

For example, I quickly fix a bug. The code is ugly and I don't want to commit it yet. So I add the bugfix files. Then I clean up the code (before commiting). Now I can do another diff between the staged and unstaged files, checking that it looks better than before, and still works. This way there is 1 clean commit "bugix" and not 2 commits "bugfix" and "bugfix code cleanup"

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

#274

Post by MattyRad »

> Bizarrely, git won't do a dif of files that have been add-ed to your staging area without this flag

Not sure what's bizarre about that. Doing so helps keep your commits clean and helps git tools (diff, git-gutter, etc) by ignoring things you've already stated are complete.

For example, I quickly fix a bug. The code is ugly and I don't want to commit it yet. So I add the bugfix files. Then I clean up the code (before commiting). Now I can do another diff between the staged and unstaged files, checking that it looks better than before, and still works. This way there is 1 clean commit "bugix" and not 2 commits "bugfix" and "bugfix code cleanup"

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

#275

Post by oneloop »

crdoconnor wrote: post #126
oneloop wrote: post #122

Git is complex and nuanced, and short term purple think it's faster to memorize some commands instead of understanding the fundamentals. I kept having problems with git, so I read a fucking book on it https://git-scm.com/book/en/v2 I'm not saying I never get into situations I can't get myself out of, but the examples in the oh shit website now look like obviously trivialities.

It's easier to figure out the various workflows you need (most teams need very few - work on feature, sync code, commit/push/issue PR, release) and then scripting them. I noticed that git errors on my team were almost eliminated when we started doing that - especially once I started adding sanity checks to the git workflows. It also allowed members of the team who previously struggled with git to contribute much more…

> It's easier to figure out the various workflows you need

Fine, that might be cheaper than properly training your employees. Of course, if your employees aren't training themselves out of genuine interest that's really the only option.

But then once something goes wrong you'll have to resort to "oh shit" websites and hope that you can the exact issue that you're having, since you really don't understand what's going on anyway.

> This worked out much better than the git course people were sent on.

I submit this must be because people came out of the course without really understanding the tool. Why they didn't understand I won't speculate, but I submit that they didn't.

EDIT: I think that which one is more appropriate depends on where it's used. I a big structured company I can believe that yours is better, or even crucial. But on a scenario where I'm starting a company with two other guys on a garage, I wouldn't want the guys to be the type of people who can only use a workflow that someone designed for them and never had the interest to dig under.

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

#276

Post by recursive »

busterarm wrote: post #252
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 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.

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

#277

Post by infodroid »

ewjordan wrote: post #58
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…

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible softwar…

> terrible software

The Git DAG and its content-addressable file system are an elegant solution to the problem of distributed version control. The implementation is clean and dead-simple, yet immensely powerful. This is the basis of good engineering.

> an even worse UX

Git was designed to expose its underlying implementation and not to isolate the user from it. Unlike other systems, its subcommands give the user the ability to manipulate the underlying data structure directly.

That doesn't mean it has a bad UX. Just that it has the UX of a power tool.

I also think that Git played a big role in the growth and popularity of command-line tools over the past decade. And that its interface inspired the subcommand pattern that is now commonplace in docker, vagrant, and others.

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

#278

Post by fizzbatter »

I constantly wonder if there's a "better CLI UI" that can be made for git, even if simply a wrapper around git.

Ie, if the implementation of Git is right, but only the cli commands/etc are wrong.. what would the right UX be? What would a friendly UX look like?

Seems like something a lot of people could love - even if blasphemy to Git purists.

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

#279

Post by mjevans »

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?

I think the implication is that the freshly checked out state of the files was used.

I do agree that reproducible differences in performance should be measured, not single tests.

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

#280

Post by BeetleB »

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.

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.

Post reply on HN