git-diff-stages?

git-diff-stages?

[Junio C Hamano]

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.

deprecating more

[Junio C Hamano]

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

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

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.

Re: deprecating more

[Horst von Brand]

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

[About axing programs]

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

Given that you can just tar the whole repository up and handle it that way,
all that work makes little sense.

Note that bk export (and cg-export) copy the current snapshot into a
directory or tarball, so this doesn't do what I'd expected.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: deprecating more

[Linus Torvalds]

On Fri, 16 Sep 2005, Junio C Hamano wrote:
> 
> 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

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

Re: deprecating more

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

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

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?

Re: deprecating more

[Linus Torvalds]

On Fri, 16 Sep 2005, Junio C Hamano wrote:
> 
> 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

Re: deprecating more

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Fri, 16 Sep 2005, Junio C Hamano wrote:
>
>> 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.

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

diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -245,7 +245,7 @@ gb=$(tput setab 2)
 rb=$(tput setab 1)
 restore=$(tput setab 9)
 
-if [ `git-rev-tree release ^test | wc -c` -gt 0 ]
+if [ `git-rev-list release ^test | wc -c` -gt 0 ]
 then
 	echo $rb Warning: commits in release that are not in test $restore
 	git-whatchanged release ^test
@@ -262,7 +262,7 @@ do
 	status=
 	for ref in test release linus
 	do
-		if [ `git-rev-tree $branch ^$ref | wc -c` -gt 0 ]
+		if [ `git-rev-list $branch ^$ref | wc -c` -gt 0 ]
 		then
 			status=$status${ref:0:1}
 		fi

Re: deprecating more

[Tony Luck]

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

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