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

331–340 of 352 posts

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

#331

Post by BeetleB »

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…

>"git grep" is 2% of all the commands I type. I type it 10x as often as "ls". So, yeah, its speed matters to me. :)

I appreciate that - I know the frustration of tools being a bit laggy.

However, I think you are falling for the [Endowment Effect](https://en.wikipedia.org/wiki/Endowment_effect). You are accustomed to it, so the alternative seems horrible without you really thinking it through. If you were not already using grep, the search issue would not be a big deal.

I already pointed out how merely excluding ".hg" from your search will save all the time, and this benefit you speak of disappears (please correct me if I'm wrong).

On my shell, that's as simple as creating an alias for grep to always exclude ".hg".

Yes, I'll grant that searching Mercurial repositories is a lot slower. But you need to understand that the obvious solution is not "Switch to git". There are simpler solutions.

In that sense, this seems to be a very insignificant benefit of git, even for people like you who need to search often.

To beat a dead horse, if you had two developers: One using git and the other using mercurial, and both need to search heavily, the mercurial person will likely have already solved the problem in one way or another. It'd be a bit silly for an observer to look at them and say "Ah, Git is so much better because it did not require a shell alias for faster searches!"

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

#332

Post by whataretensors »

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.

I think as engineers we should understand how our tools work.

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

#333

Post by jlebar »

Hello71 wrote: post #328
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 a highly misleading comparison. something slightly more accurate (although this time somewhat more hg-biased): $ time taskset -c 2 hg grep CUDA >/dev/null taskset -c 2 hg grep CUDA > /dev/null 25.04s user 0.46s system 99% cpu 25.514 total $ time taskset -c 2 sh -c 'git grep --cached -l CUDA | xargs -n 1 git blame >/dev/null' taskset -c 2 sh -c 4.85s user 0.13s system 97% cpu 5.097 total

> this is a highly misleading comparison.

Why? When I do hg grep, it doesn't show me blame or anything; the output looks almost identical to the output of git grep. If it's doing work and then throwing it away, why is it fair to force git to do the same work and then also throw it away?

(I'll also point out that git is still 5x faster in this comparison. :)

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

#334

Post by jlebar »

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.

As Jtsummers pointed out downthread, hg grep searches all revisions by default. No wonder it's so slow.

  $ time hg grep --rev tip CUDA > /dev/null
  real	0m0.075s
  user	0m0.055s
  sys	0m0.020s
Much better. Still much slower than git, which doesn't matter for this small repo but would definitely matter on a larger repo. But better. And hg lets you define aliases, so you don't have to remember to type "--rev tip".

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

#335

Post by atsaloli »

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 a big fan of GitLab. Clean design, intuitive interface, many features.

Disclaimer: I'm now a GitLab authorized training partner and reseller. The community edition is free. :)

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

#336

Post by Pinckney »

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…

From man git-stash:

"Applying the state can fail with conflicts; in this case, it is not removed from the stash list. You need to resolve the conflicts by hand and call git stash drop manually afterwards."

Or do I misunderstand you?

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

#337

Post by breatheoften »

OJFord wrote: post #151
breatheoften wrote: post #114

Earlier quoted context omitted.

Its true -- and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line. Distributed vc is conceptually nuanced, but not overly complicated -- the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that y…

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.

I actually used to think similarly before I found git up -- although to me it wasn't about switching window context away from the terminal but rather switching away from the text editor. I imagined that the ideal place for featureful visualization/interaction with the repo would be in the text editor/ide. In reality though -- i really like having the separate window -- it's always there, does one thing and does it well, and it's easy to switch to when I want to take a look at the state of my repo/upstream branches/any dirtiness in my checkout (what exactly have I done recently?). I regularly use three editors when working on different platforms -- Xcode, android studio, atom -- sometimes it's convenient to use in ide repo-driven features (blame, sometimes historical diffs for a single file), however very often I'm actually more interested in quickly seeing diffs for files other than the one(s) I'm currently editing -- so switching to a separate app context that's all about showing repo info tends to be the fastest way to see the relevant info I want side by side without changing away from the editing context I want. More often than not navigating to most relevant diffs within the ide would actually involve more expensive context switching -- for me I'm discovering that it's always somewhat high risk to switch editor contexts -- editing text is just such a powerful interface that it tends to easily lead down rabbit holes that take me further from the most relevant info for my current task context. Once I have the most useful buffers in the right windows, with maybe some reasonable things in the editor navigation stack -- changing the editor views at that point comes with a pretty high risk of straying off task -- or operating for awhile with the non optimal set of editor windows in front of my face -- which at some point I'll realize is dumb/wastes energy and fix -- but energy was already spent in the meanwhile ...

Honestly I'm not aware of any common repo tasks that I could more efficiently complete via the command line vs gitup. There are good keyboard shortcuts for everything in gitup so most everything I do doesn't even involve the mouse.

Also -- I'm the kind of person who's always got a set of terminal windows open and definitely uses them often (almost never use Finder, hate taking my hands off the keyboard to reach for the trackpad). At this point -- I never reach for the git cli over gitup (except when cloning a new repo).

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

#338

Post by RJIb8RBYxzAMX9u »

chousuke wrote: post #305
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…

I feel like people's opinion of git's usability is lower than what it actually is. Certainly, it's got a lot of different switches and stuff, but since its data model is so simple, you can always understand what it's doing to your data. So you can read a description of what a switch does, and then understand exactly what will happen when you use it. (The exception to this is automatic merge conflict resolution with r…

> [C]an you tell me how to do the equivalent of "git log -p"? Last time I checked (SVN 1.8) that's not very trivial.

svn log --diff, added in 1.9. Also doable with a little (est. > Or how to revert a commit? IIRC that requires a merge.

git and svn disagree on whether history should be permanent or not.

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

#339

Post by RJIb8RBYxzAMX9u »

marcinkuzminski wrote: post #264
ewjordan wrote: post #255

Earlier quoted context omitted.

Yep, Mercurial's the one. It's a shame that it lost the war, they actually seemed to care about providing a good experience to their users. There are, of course, a few technical differences between it and git, but I personally never felt like they were troublesome enough to make up for the vast difference in usability.

I think Mercurial hasn't lost it yet. I speak as a creator of Mercurial Source Code management system (RhodeCode) We see that a lot of companies(our clients/users) adopting Mercurial, you just don't hear about it. Often those are companies with employees that don't tweet or post to HN ;) RhodeCode is used also in around 60 universities, and we learned that in a lot of them they teach Mercurial as well as Git. For a l…

I don't think hg is going anywhere, if CVS is still alive and kicking in 2016, and especially since Facebook's using it. However, IMO hg lost when even python switched to git.

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

#340

Post by csbubbles »

You know, a few years back I had exactly the same attitude towards Git. I hated it, tried to approach multiple times and still hated it. But after working with Git on multiple projects, and having developed some deeper understanding of how things work there, I honestly think now that Git is one of the best tools that have been invented over last 20 years for improving the development processes and engineering excellence. I don't really want to defend it, the learning curve is apparently pretty steep (at least it was for me), but I would just recommend to not give up and keep trying. There are some good tutorials how to handle it and why it's helpful (Atlassian's Git book, for instance).
Post reply on HN