Feature request: git history grep

[slavaGanzin]

Hello again.

This is command for greping git history in current branch:

#!/usr/bin/env sh
git rev-list --all --simplify-merges --walk-reflogs --abbrev-commit | xargs git grep $1 | fzf

Which can be used as:

$ git find anyTerm

This command uses https://github.com/junegunn/fzf (narrow-like tool) for additional filtering.

May be you'll find this use case appropriate for implementing in narrow

[t9md]

I'm intentionally limiting what narrow to do. I defined narrow's role as open item which item have filePath and point(row and column in file). I don't want to use(or enhance) narrow as narrow-anything package.

What you want to open after you grepping git history? Open file for specific git-rev?

Need to know further practical situation/background.

[slavaGanzin]

What you want to open after you grepping git history?

All git revisions of files with a needle. This is very convenient when you work on some project with a bunch of refactoring-lovers.

Practical situation:

I rewrite some code couple of times, and want to review(and copy) some code which is not present in current codebase. Let's say I removed some method/class and all it's uses, but now want to revert it back.

I print git find myAwesomeClass find last(or review all) occurrence(s), copy it and paste in my current code. In another words: I want to review history of previous implementations of something.

This can be done with git-time-machine for atom, but only if changes was done in one file, which sometimes isn't enough.

[t9md]

I print git find myAwesomeClass find last(or review all) occurrence(s), copy it and paste in my current code. In another words: I want to review history of previous implementations of something.

I want to know what narrow have to do if I implement that feature. I don't know git workflow well. That might be reason why I can't understand what-narrow-have-to-do from above your comment.

1. read searchTerm from user via min-input form
2. execute git rev-list --all --simplify-merges --walk-reflogs --abbrev-commit and render each line of output as item
3. user can narrow these lines
4. when confirmed???

checkout that file? search matching line to place cursor?

[slavaGanzin]

Just open that file-revision in new unnamed buffer and place cursor on specified line.

search matching line to place cursor?

No need for searching. if you add -n to git grep output will contain revision:file:line

$ git rev-list --all --simplify-merges --walk-reflogs --abbrev-commit | xargs git grep -n debug
...
de6bc40:lib/debug.js:25:const logFile = msg => R.tap(x => debug(`debug:${msg}`)(
de6bc40:lib/debug.js:31:module.exports = {D, debug}
...

read searchTerm from user via min-input form

I'm a bit confused with mini-input. Why you can't consider first word as query for ag/git/any and the rest as additional filtering? As I saw you use color designation to separate concepts. I think it wouldn't be confusing to get rid from that input.

Of course you will face general search problems, like do not start search untill 3 characters entered or throttle search for 300 ms(which I prefer). But it will make it way more interactive

user can narrow these lines

It would be awesome to keep live-updating open buffer like with git-diff-all

when confirmed???

Your cursor goes to that file and narrow closes

Thanks

[t9md]

I'm a bit confused with mini-input. Why you can't consider first word as query for ag/git/any and the rest as additional filtering? As I saw you use color designation to separate concepts. I think it wouldn't be confusing to get rid from that input.

Of course you will face general search problems, like do not start search untill 3 characters entered or throttle search for 300 ms(which I prefer). But it will make it way more interactive

This is FAQ, everyone asks, I once have that idea but postponed since I have lots of TODO at that time. But now I'm experimenting this idea and seems to work(this is very WIP state).

https://github.com/t9md/atom-narrow/pull/205

But If I take searchTerm from 1st word of query, user cannot search space included word like

• abc def as searchTerm
• hello word as searchTerm, ending space

Since space is used as query-separator. So only abc and hello would be treated as searchTerm unless I come up with some good idea.

Let user confirm search-term by enter might be solution but bit ugly. Any idea?

[slavaGanzin]

I think escaping spaces with backslash would be suitable. (I'm just mimicking fzf/unix behaviour)

And what about enabling regexp by default? (Or just making an option for that) As I see in my experience people divide in two categories:

1. one's that use regexp all time
2. one's that never-ever use even asterisks and treats smart case as magic

[t9md]

one's that use regexp all time one's that never-ever use even asterisks and treats smart case as magic

I'll make this controllable by config depending on user's preference.

For search option button, it's already in TODO list of #205.

Live search with throttling is heavy stuff, so I'll start with simply migrate current mini-editor behavior into normal narrow-ui. And let user explicitly confirm search word.