Re: Deprecation/Removal schedule

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 5, 2007, 09:33 UTC
Message-ID: <eq6tj6$80m$2@sea.gmane.org>
In-Reply-To: <7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 14 quoted lines

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

Show 5 quoted lines

> * 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?

Show 6 quoted lines

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

Show 5 quoted lines

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