git-diff-stages?

Is anybody actually using this program? If not I'd like to deprecate it now and remove it before we hit 1.0. As far as I can tell it is not very useful.

Junio C Hamano <junkio@cox.net> writes:

The same goes for the following programs:

    git-diff-helper
    git-diff-stages
    git-export
    git-rev-tree

Among them, I could be talked into keeping git-export on the condition that we will add a counterpart git-import that can read git-export output and recreate an identical repository [*1*]; without something like that, I doubt its usefulness, especially since "git-whatchanged" is far more useful for everyday use.

[Footnote]

*1* which I think actually is impossible without fixing git-export first so that it exports the initial commit. I may be mistaken.

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

I don't think there is any point.

git-export was done as a concept example on how easy it is to export the git data to something else. It's much less powerful than ny number of trivial one-liner scripts now, and real exporters would not ever use git-export.

It's obviously much less powerful than "git-whatchanged", or just about any combination of git-rev-list + git-diff-tree.

So drop it.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

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.

What do you think about the other commands I mentioned?

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

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.

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

Linus Torvalds <torvalds@osdl.org> writes:

I found one in our source. Tony, is the following change acceptable to you?

------------ [PATCH] Use git-rev-list not git-rev-tree where appropriate.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

Sure ... I'll be glad to see git-rev-tree go. For some reason it got wired into my fingers early on, and I keep typing it when I mean to use git-rev-list, then stare at the screen all confused when it complains about the arguments I gave it.

-Tony