Re: deprecating more

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 17, 2005, 02:50 UTC
Message-ID: <Pine.LNX.4.58.0509161938580.26803@g5.osdl.org>
In-Reply-To: <7vr7boe8a8.fsf@assigned-by-dhcp.cox.net>

On Fri, 16 Sep 2005, Junio C Hamano wrote:

Show 6 quoted lines

> 
> I'm happy to hear an argument to drop it, but I would like to
> make sure that you do realize that git-whatchanged is not a
> convenient way to truly "export" for later recreation of
> identical repository, due to its indentation and truncation
> behaviour.  Not that *I* think that matters.

Well, the thing is, a true exporter probably doesn't want to use patches at all.

A truly good exporter would likely use

	git-diff-tree -M -r

or something to generate the list of filenames and versions, and then work on that. You really _have_ to, in order to get things like binary files right.

Anything that is based on diffs would suck.

Also, I suspect that to get the list of commits to export, a real exporter is likely to first just do something like

	git-rev-list --parents --topo-order prev..

and generate the commit topology from there. Then just either use the C library interfaces to suck in the commit messages, or just use git-cat-file. And then git-diff-tree -M (or perhaps -C, if the repo-to-be-exported-to knows about copies) to actually generate the revision info.

> What do you think about the other commands I mentioned?

I think they can all go. I think some old scripts migth still use git-rev-tree, but it really is clearly inferior in every way to git-rev-list that such scripts should be fixed anyway. Fixing them should be pretty easy.

(The packed format actually makes git-rev-tree at least ok from a performance angle, even if it has to walk all the way to the root. But I _seriously_ doube you want to use it on any big repo anyway, and definitely not with an unpacked one).

		Linus