# git-diff-stages? 7 messages from 2005-09-17 to 2005-09-17. Participants: Junio C Hamano, Linus Torvalds, Tony Luck. Thread: https://gitlist.dev/t/1837 ## Junio C Hamano, 2005-09-17 01:04 Subject: git-diff-stages? Message-ID: <7vd5n8fqso.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd5n8fqso.fsf%40assigned-by-dhcp.cox.net ``` 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, 2005-09-17 01:31 Subject: deprecating more Message-ID: <7vzmqceayd.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzmqceayd.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vd5n8fqso.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano 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. ``` ## Linus Torvalds, 2005-09-17 01:59 Subject: Re: deprecating more Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509161856260.26803%40g5.osdl.org In-Reply-To: <7vzmqceayd.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Junio C Hamano, 2005-09-17 02:29 Subject: Re: deprecating more Message-ID: <7vr7boe8a8.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7boe8a8.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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? ``` ## Linus Torvalds, 2005-09-17 02:50 Subject: Re: deprecating more Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509161938580.26803%40g5.osdl.org In-Reply-To: <7vr7boe8a8.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Junio C Hamano, 2005-09-17 05:28 Subject: Re: deprecating more Message-ID: <7vfys4e003.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfys4e003.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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 --- 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 ``` ## Tony Luck, 2005-09-17 06:13 Subject: Re: deprecating more Message-ID: <12c511ca05091623135ccbcae1@mail.gmail.com> URL: https://gitlist.dev/e/12c511ca05091623135ccbcae1%40mail.gmail.com In-Reply-To: <7vfys4e003.fsf@assigned-by-dhcp.cox.net> ``` > 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 ```