Thread (8 messages) 8 messages, 2 authors, 2019-11-27

Re: A new idea to extend git-blame

From: chen bin <hidden>
Date: 2019-11-27 07:32:51

HI, Jeff,
Just double checking, the feature I suggested is fine, right? I will
send the patch asap. It may take 2 weeks to implement.

On Tue, Nov 26, 2019 at 4:36 PM chen bin [off-list ref] wrote:
The problem of recursive blaming with 3rd party script is it's slow.
The script have to restart git process multiple times. Besides, as I
already did in Emacs (see
https://github.com/redguardtoo/vc-msg/commit/1f7775f951fdd9e6571afbb3a767c42d20617f52),
it's still lots of code.

So if it's possible to use a simple cli option like `git blame
-S"text"`to do the same thing, it would be easier to migrate vc-msg's
functionality to other text editors.

On Tue, Nov 26, 2019 at 3:55 PM chen bin [off-list ref] wrote:
quoted
I re-tested `git log -L20,20:README.md` in git's own repo with HEAD
d01d26f2df. Looks git log is not what I expected. The output contains
many unrelated commits. So it will be slow in real project.

A recursive blame with the algorithm I suggest will get correct commit
in short time. So my suggestion still hold.

I could submit a patch to enhance blame.

On Tue, Nov 26, 2019 at 1:16 AM Jeff King [off-list ref] wrote:
quoted
On Mon, Nov 25, 2019 at 11:41:55PM +1100, Chen Bin wrote:
quoted
The key algorithm is simple,

The algorithm only works for one line blame and the user must
select text inside the line first.

Step 1, `git blame -L6,1 --porcelain -- hello.js` output,

    4f87408612e0dacfd89a1cd2515944e21cf68561 6 6 1
    skip...
    filename hello.js
     doit({bad: 'destroy world', good: 'hello world', ...});

I got the commit id (1st column), the line number (2nd column),
file name (hello.js) and the code line (last line).

Step 2, if the code line does not contain the selected text, the
  recursive search stops

Step 3, or else use commit id, line number and file name to build
  new git blame cli, like,

`git blame -L line-num,1 --porcelain 4f8740^ file-name`

Step 4, execute new git blame command and start from Step 1
This sounds a lot like how git-log's "-L" option works, which tries to
find the history of a line over many changes.

It's also similar to the "re-blame from parent" feature of many blame
viewers. There we have a human in the loop saying "no, this is not quite
the change I'm looking for; go back further".

-Peff


--
help me, help you.


--
help me, help you.


-- 
help me, help you.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help