From: Linus Torvalds Date: Sat, 17 Sep 2005 02:50:35 GMT Subject: Re: deprecating more Message-ID: 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