On 3/23/2023 9:41 PM, Junio C Hamano wrote:
> Jacob Keller <jacob.e.keller@xxxxxxxxx> writes:
>
>> From: Jacob Keller <jacob.keller@xxxxxxxxx>
>>
>> The --contents option can be used with git blame to blame the file as if
>> it had the contents from the specified file. This is akin to copying the
>> contents into the working tree and then running git blame. This option
>> has been supported since 1cfe77333f27 ("git-blame: no rev means start
>> from the working tree file.")
>>
>> The --contents option always blames the file as if it was based on the
>> current HEAD commit. If you try to pass a revision while using
>> --contents, you get the following error:
>>
>> fatal: cannot use --contents with final commit object name
>>
>> This is because the blame process generates a fake working tree commit
>> which always uses the HEAD object.
>
> "the HEAD object as its sole parent."
>
Ah, good correction.
>> Fix fake_working_tree_commit to take the object ID to use for the
>> parent instead of always using HEAD. If both a revision and --contents
>> is provided, look up the object ID from the provided revision instead of
>> using HEAD.
>
> An obvious enhancement.
>
> As the original author of 1cfe7733 (git-blame: no rev means start
> from the working tree file., 2007-01-30), I am not sure if the verb
> "fix" is fair to describe this change, though.
Right, this is an enhancement, not a fix. I reworded this in v2.
> If you update the
> working tree file with contents that is vastly different and totally
> unrelated to the version at HEAD, then with this new feature, your
> "blame" can start at the working tree file, and then some commit
> that is totally unrelated to HEAD, and down the history from it, and
> everything should make sense, but if you smudge your working tree
> files that way, it would be quite awkward to use the working tree to
> advance the history that leads to HEAD. That is the reason why I
> designed the "fake commit based on off-history contents" features to
> work only with HEAD. But unlike actually messing with the contents
> of the working tree files, feeding a temporary contents via the
> "--contents" option has much less chance of breaking the next
> commit, so I do not have any objection to this patch.
> > Thanks.
Right. This doesn't change the behavior for if --contents is not
provided. If a revision is specified, we ignore the working tree and
just use the revision. If no revision is specified, we use HEAD but
generate the fake working commit that includes the staged changes. Using
working tree with arbitrary commits doesn't usually make sense. If you
*do* actually want that, its possible to do now with "--contents
path/to/working-tree-file", but you have to opt-in by using --contents.
The change should only modify the behavior if --contents is provided. In
that case, we always use that file contents and assume you know what
you're doing with respect to the contents you want to blame.
