3 ms·

> 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

by jlebar 10y ago

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

BeetleB 10y ago
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.
- Jtsummers 10y ago
  16 seconds versus a fraction of a second. There's a big difference, somewhere, in what these two systems are doing to accomplish (ostensibly) the same task. And if it's not accomplishing the same task, they shouldn't be using the same verb (grep) for it. And I disagree with this point: Things like search time are *not* a productivity bottleneck. I maintain old codebases. I don't know them by heart, I didn't write them and the documentation is often poor (for the codebase, the specs are usually decent, but that's the system spec, not the code spec). Search is critical for me to get around these things. A 16s search would be incredibly annoying and bottlenecking compared to one that's nearly instant. Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems. EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.
- jlebar 10y ago
  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 grep' ~/.bash_history | wc -l 407 $ grep -w '^ls' ~/.bash_history | wc -l 37 $ wc -l ~/.bash_history 19421 "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. :)
  - ubernostrum 10y ago
    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.
  - BeetleB 10y ago
    >"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 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!"

by jlebar 10y ago

BeetleB 10y ago

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.

Jtsummers 10y ago
16 seconds versus a fraction of a second. There's a big difference, somewhere, in what these two systems are doing to accomplish (ostensibly) the same task. And if it's not accomplishing the same task, they shouldn't be using the same verb (grep) for it. And I disagree with this point: Things like search time are *not* a productivity bottleneck. I maintain old codebases. I don't know them by heart, I didn't write them and the documentation is often poor (for the codebase, the specs are usually decent, but that's the system spec, not the code spec). Search is critical for me to get around these things. A 16s search would be incredibly annoying and bottlenecking compared to one that's nearly instant. Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems. EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.
jlebar 10y ago
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 grep' ~/.bash_history | wc -l 407 $ grep -w '^ls' ~/.bash_history | wc -l 37 $ wc -l ~/.bash_history 19421 "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. :)
- ubernostrum 10y ago
  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.
- BeetleB 10y ago
  >"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 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!"