Re: [PATCH 2/5] Make mktag a builtin.

[Brandon Casey <casey@nrlssc.navy.mil>]

Junio C Hamano wrote:
> drafnel@gmail.com writes:
> 
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> 
>> @@ -306,6 +305,7 @@ BUILT_INS += git-fsck-objects$X
>>  BUILT_INS += git-get-tar-commit-id$X
>>  BUILT_INS += git-init$X
>>  BUILT_INS += git-merge-subtree$X
>> +BUILT_INS += git-mktag$X
>>  BUILT_INS += git-peek-remote$X
>>  BUILT_INS += git-repo-config$X
>>  BUILT_INS += git-show$X
>> @@ -423,6 +423,7 @@ LIB_OBJS += log-tree.o
>>  LIB_OBJS += mailmap.o
>>  LIB_OBJS += match-trees.o
>>  LIB_OBJS += merge-file.o
>> +LIB_OBJS += mktag.o
> 
> This is unusual for a builtin.  Why didn't it migrate to builtin-mktag?

I didn't know how to do it.

I was trying not to do a code move and a code change at the same time.
I didn't think I should move the non-builtin mktag.c to builtin-mktag.c,
and then after I modified mktag to be a builtin I knew I was moving it
to builtin-tag.c so I didn't see a point to renaming it.

Also, I decided about those things _before_ I realized how small the changes
would be to mktag to make it a builtin.

Do you think the modified patch you posted conflicts with the idea that
"code move should be separate from code change"?

-brandon