Re: Deprecation/Removal schedule

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 5, 2007, 16:26 UTC
Message-ID: <Pine.LNX.4.64.0702050814380.8424@woody.linux-foundation.org>
In-Reply-To: <7v8xfdnlqm.fsf@assigned-by-dhcp.cox.net>

On Sun, 4 Feb 2007, Junio C Hamano wrote:

Show 5 quoted lines

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

Somebody should at least document the differences before it's depracated.

I think git-whatchanged ends up being equivalent to

	git log --full-history --raw -r

but I didn't really check if there's something else.

Same goes for "git-am". I use "git-applymbox", and I'll happily switch to git-am, but I'd like somebody who knows to document the differences when it gets deprecated. I use "git-applymbox -u", and I guess I just should change that to "git-am --utf8".

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 think they're useful to keep around, if for no other reason than as starting points for others.

That said, I probably agree with your other examples:

> * git-diff-stages
> * git-lost-found
> * git-local-fetch, git-ssh-fetch and git-ssh-upload
> * contrib/colordiff

Although the git-ssh-fetch thing might be useful if you try to fix a tree that got corrupted and is missing an object (the native git protocol won't help you, since it assumes both trees are complete, while the stupid object fetching can pick out individual missing objects, I think).

That said, I don't think anybody would really ever fix their trees that way. It's more likely that you'd just fetch the whole repo and add the missing objects that way (ie do a clone, copy the pack-file, and repack the resulting mess to get a nice clean and working repository again).

		Linus