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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eugen Konkov <kes-kes@xxxxxxxxx> writes:

> I agree with your complex example.

Note that it is a norm, not anything complex, that we do not rename
a file wholesale.

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

So you used to have A and somebody renamed that into C in the past.
The content of C in the current version is what you used to have in
A.

What should happen if you also have A, whose contents do not have
any relation to that old A, in today's code?

What should happen if you also used to have C, whose contents do not
have any relation to that old A or current C?

What happens if you added such random guessing and you were not so
familiar with the project history to know these unrelated A's and
C's that used to exist in the past?

Current Git _consistently_ behaves, even in the presense of anything
that can lead to confusing behaviour.  When you ask

    git blame OLD -- A

it does not matter if you have an unrelated A in the revision that
you happen to have checked out in your working tree (i.e. HEAD).
The above command line talks about the old revision OLD and A talks
about the path A in that old revision.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]