Jakub Narebski <jnareb@xxxxxxxxx> writes:
> "Abimbola via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
>> Subject: Re: [PATCH 1/5] remove-annotate: change cmd_annotate to cmd_blame
>> From: Abimbola <craftwordltd@xxxxxxxxx>
>>
>> Changing this command is to remove the annotate.c file which does almost
>> the same thing as blame.c. git annotate will invoke blame directly
>
> Both the summary and the detailed description of the changes is not
> entirely clean. What is this 'remove-annotate' subsystem? Why we would
> want to change cmd_annotate to cmd_blame -- and wouldn't we loose
> difference (in defaults, and thus in output format) between git-blame
> and git-annotate?
>
>>
>> Signed-off-by: Abimbola <craftwordltd@xxxxxxxxx>
>
> Why not
>
> Signed-off-by: Abimbola Olaitan <craftwordltd@xxxxxxxxx>
>
>> ---
>> git.c | 143 +++++++++++++++++++++++++++++++++-------------------------
>> 1 file changed, 82 insertions(+), 61 deletions(-)
>
> Looks like a big change, strangely. And annotate.c is not actually
> deleted...
Thanks for all the good comments. The first priority of any work in
this area is not to lose the different defaults between "annotate"
and "blame", as the former has ("had", at least when we invented
"blame") known uses in widely used script(s), and the solution we
took was to use a small annotate.c shim to tell the blame machinery
to emit historical "annotate" output format. If we can do so
without having the shim, that would be OK. If removal of shim loses
the distinction, then it is not.
I suspect that cmd_blame() can be taught to look at argv[0] and
pretend "-c" was given on the command line, and then the command
dispatch table can call cmd_blame() upon seeing "annotate" as the
subcommand name, but I haven't actually tried it so there may be
hidden dragons.
Thanks.
