Re: Feature request: implement '--follow' option for `git blame`

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Feature request: implement '--follow' option for `git blame`

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:23

KES [off-list ref] writes:
**UPDATE:** Short answer

`git blame` follow renames but not for `git blame COMMIT^ -- <filename>`
Suppose you have file A and file B in your version v1.0.

Six month down the road, the code was much refactored, and you do
not need the contents of these two files separately.  You have
removed A and B and much of what they had is now in file C.  That is
the current state.

    git blame -C HEAD -- C

may follow the contents from both just fine, but if you _were_
allowed to say

    git blame v1.0 -- C

what does it even mean?  C did not exist v1.0 at all.  Are you
asking to follow the contents of A back then, or B?  How did you
tell you meant A and not B when you told it C in this command?

"git blame" follows content movements, and never treats "renames" in
any special way, as it is a stupid thing to do to think a rename is
somehow special ;-)

The way you tell what content to start digging from to the command
from its command line is to give starting point commit (defaults to
HEAD but you may give COMMIT^ as your example) and the path in that
starting point.  As it does not make any sense to tell C to Git and
then magically make it guess you meant A in some cases and B in some
other.  If v1.0 did not have C, the only sensible thing to do is to
exit instead of making a guess (and without telling the user how it
guessed).

Re[2]: Feature request: implement '--follow' option for `git blame`

From: Eugen Konkov <hidden>
Date: 2016-06-15 23:04:24

Здравствуйте, Junio.

Вы писали 8 апреля 2015 г., 5:48:36:

JCH> KES [off-list ref] writes:
quoted
**UPDATE:** Short answer
quoted
`git blame` follow renames but not for `git blame COMMIT^ -- <filename>`
JCH> Suppose you have file A and file B in your version v1.0.
....
As it does not make any sense to tell C to Git and
JCH> then magically make it guess you meant A in some cases and B in some
JCH> other.  If v1.0 did not have C, the only sensible thing to do is to
JCH> exit instead of making a guess (and without telling the user how it
JCH> guessed).

I agree with your complex example. But it will be great to guess in simple case, when in version v1.0 only one file A which were renamed into C half year later.

`git blame COMMIT^ -- C`

For complex example the clue will be if user supply line number he want to blame. So if user supply line 10 we follow A, if user supply 30 we follow B.
Simple and great =) (I mean usefull for people)

`git blame --line 10 COMMIT^ -- C`   
`git blame --line 30 COMMIT^ -- C`







-- 
С уважением,
 Eugen                          mailto:kes-kes@yandex.ru
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help