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

311–320 of 352 posts

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

#311

Post by ubernostrum »

jlebar wrote: post #309
BeetleB wrote: post #289

Earlier quoted context omitted.

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

Things like search time are *not* a productivity bottleneck. I would recommend, as a general rule, not generalizing from your development experience to everyone's development experiences. I happen to know that git grep is very carefully optimized. Someone cared a lot about making it run fast. Seems like a good guess that they did so because it was important to them or someone else, not just for funzies. $ grep '^git…

I would recommend, as a general rule, not generalizing from your development experience to everyone's development experiences.

What's interesting here is that it's the exact thing happening. Someone asked about how much hidden cost there is from the time people waste fighting to make git do what they need it to do, and it got derailed with a discussion of how `git grep` is faster than `hg` grep`.

I'm sure it's great for you that git's grep is fast. But the time you gain from how much faster it is than hg probably is strongly outweighed by the time other people lose to struggling with git's interface. Unfortunately there's no easy way to benchmark that.

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

#312

Post by ubernostrum »

BeetleB wrote: post #282
exDM69 wrote: post #253

Earlier quoted context omitted.

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

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

The typical advice -- which you'll see in this thread and elsewhere -- is that anyone who uses git should learn git's internals, and preferably up-front, since apparently that will magically cause git to make sense.

I'm a bit put off by the idea, myself.

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

#313

Post by ramses0 »

froh42 wrote: post #83

With all these recipies - one thing I do whenever I attempt some stunt in git: I assign temporary tags to every changeset that's important. git tag tmp git perform-stunt This eases undoing the stunt without needing to find the "before" state from reflog. And if you use a graphical log viewer (I like SourceTree on Mac) you'll see the tagged state in the history view - which makes things a lot clearer. And to be aware…

http://www.robertames.com/blog.cgi/entries/git-in-two-ten-mi... ... feedback welcome, but I feel like I go into a bit more depth using similar metaphors.

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

#314

Post by DiThi »

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?

I'm surprised nobody mentioned Git Extensions yet. My absolute favorite Git UI, better than my previously favorite git-cola.

https://gitextensions.github.io/

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

#315

Post by ThatGeoGuy »

shandor wrote: post #246
jryan49 wrote: post #224

Earlier quoted context omitted.

Never do this on a merge commit however. Unless you are prepared: https://git-scm.com/blog/2010/03/02/undoing-merges.html

This is why rebase is so, so much better than merge. And it's infinitely better for bisecting, too. Simple, completely linear history for origin/master is just so powerful in many that aspects that I'm constantly baffled why merging seems to be the flow mostly being talked about. Now someone usually comes and says that merges are superior for long running branches. Which may be true in some aspects, but when you have…

For those of us who are uneducated / haven't seen this before: how do you use rebase to merge a separate branch? Are you suggesting you just `git rebase my-branch` from master / develop? How do you coordinate this with multiple team members. Merges appear to work better when you have multiple team members with separate feature branches that may have some overlap (conflicts may occur, but those can be handled as they arise).

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

#316

Post by evanelias »

adamkochanowicz wrote: post #306

Great article. A couple notes Just git reset should do. The --soft flag is implicit. Amending and rebasing is something you should be careful with. If you've already pushed, you'll now need to force push. If another person has put new commits upstream, they will be wiped out irreparably. Not saying don't do it, just that it's very risky. Instead of deleting and recloning the repo at the end, if you're really at that…

Just a tiny correction: git reset defaults to --mixed, not --soft. The only difference is whether or not files are staged. Since the OP used --soft, I believe the subsequent `git add .` is unnecessary since the files should already be staged when --soft is used.

Regarding the case of an erroneous force push removing code, usually things can be recovered by looking through the reflog and doing some surgery via the lower-level plumbing commands... it's not exactly a fun process though :)

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

#317

Post by Jarwain »

swehner wrote: post #214
mathieuh wrote: post #20

I absolutely love git now. I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo. I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to…

I would not expect a university to teach git. Maybe the theory of version control systems, their history, or a comparison of different version control systems. But not how to use the tool.

I had to take a class, Principles of Software Engineering, that was a sort of hands-on class. We went over different methodoligies like waterfall vs agile, scrum, the use of kanban boards, design documents, and the use of version control. The version control lession was basically an assignment saying "do the Udacity git course". Alongside this, we had a group project where we had to, well, develop something.

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

#318

Post by exDM69 »

ubernostrum wrote: post #312
BeetleB wrote: post #282

Earlier quoted context omitted.

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

Are you suggesting a Git user will eventually need to understand it? That's a strike against Git already. The typical advice -- which you'll see in this thread and elsewhere -- is that anyone who uses git should learn git's internals, and preferably up-front, since apparently that will magically cause git to make sense. I'm a bit put off by the idea, myself.

Exactly.

It's also worth looking at git internals because it's very elegant, clean and simple. In my opinion, one of the best designed software systems I've come across.

I encourage you to look at the README in the first git commit, it's very enlightening.

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

#319

Post by Anthony-G »

From the section on using `git commit --amend`:

> This usually happens to me if I merge to master, then run tests/linters.

If this happens on more than one occasion, I’d strongly consider creating a pre-commit hook to run tests and/or lint the changed files, e.g., I run `checkbashisms` and `shellcheck` as a pre-commit hook when working on shell scripts.

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

#320

Post by Chromozon »

nhaehnle wrote: post #245
dep_b wrote: post #236

Somebody proposed to use a GUI. That doesn't solve the usability issues of Git. There's this triangle of what the user tries to do, what the commands and options are called and what they actually do. None of them really align, though with some careful use you can actually make Git do what you want - eventually. I would like to understand what's the yearly damage of such an important tool being so difficult to use. Pe…

People complain, but what's the alternative? Non-distributed VCS clearly don't cut it for many use cases, and of the other DVCS I've tried, none were really better than Git in my opinion. Sure, it depends on your workflow. But if part of your workflow is authoring sequences of commits that make sense in hindsight, then I honestly haven't seen an alternative. The point of Git is that it gets the underlying data model…

Many large companies use Perforce. Its UI is great. It's very easy to learn, so the cost of teaching new employees is low. It's hard to screw up, and when you do screw up, it doesn't require an expert to come in and fix things with obscure commands.
Post reply on HN