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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html