Re: Deprecation/Removal schedule

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:

> We seem to have accumulated some crufts, duplicated and/or
> disused features.  I think we should start planning deprecation
> and removal.
> 
> Here are potential candidates we might want to mark as
> "scheduled for removal".  Note that I threw in a bit more than
> what I seriously consider bloat, so your favorite may appear in
> the list.
> 
> * git-applymbox and git-applypatch
> 
>   Does anybody rely on them?  I think new users are all using
>   git-am (this is just what _I_ think -- please consider this
>   message as a poll to voice your objection).

If I remember correctly there are here because Linus is used to
their interface and prefers git-applymbox to git-am. I'm not sure
for example if git-am --interactive is on the par of git-applymbox -q
option (BTW. if we remove git-applymbox, we would have to remove
reference to it in git-am(1): "--interactive: Run interactively,
just like git-applymbox"). git-am also lack all git-applymbox
signoff options.

> * git-whatchanged
> 
>   This has been identical to git-log with different default
>   options.

I agree. Perhaps we should add in the documentation of git-log,
or/and in documentation of git-config, an example of "whatchanged"
alias...

> * git-p4import, git-quiltimport and contrib/gitview
> 
>   These have seen almost no activity since their appearance.  It
>   could be that they are already perfect and many people are
>   using them happily, but I find it a bit hard to believe.

I agree with removal of gitview; I'd rather leave importers, even
if they haven's seen any activity. If they import correctly, what
is to work on more?

> * git-diff-stages
> 
>   Judging from the fact that nobody complained what it does is
>   not accessible from "git diff" wrapper, I suspect nobody is
>   interested in comparing the stages while merging (I certainly
>   do not use it myself).

I think you can always use "git diff <stage1>:<file> <stage2>:<file>".
I'm not sure if it is useful or not (perhaps it is not advertised).

> * git-lost-found
> 
>   Although it has served us well, I think it is about to outlive
>   its usefulness, thanks to the recent "reflog by default"
>   change.

I agree. If it is needed, perhaps this functionality should be made
as an option to git-fsck.

> * contrib/colordiff
> 
>   This has long outlived its usefulness.

I agree.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git