On Wed, 08 Nov 2006 14:22:01 -0500, Havoc Pennington wrote: > The hangup for me remains the git UI, especially since I'm using Eclipse > a lot and would lose the GUI stuff, but also the git command line and > web frontends are pretty strange. But, this is probably not such an > issue for Fedora as it is for us desktop/web-oriented developers... ;-) Havoc, I don't follow your argument at all. If Eclipse is the important UI, then how could the git command-line be relevant at all? If an Eclipse plugin doesn't exist yet, then obviously that would need to be fixed, but I would imagine that should be extremely straight-forward for someone familiar with the Eclipse version-control plugins. And as for web frontends, I've never seen a web frontend for any source-code management tool that I've liked much at all. With git, the tool support for browsing a local version of the repository is infinitely superior than anything available in the web-based frontends. But, if web frontends are interesting, I'll comment on them a bit. Let me preface this by saying that choosing a version-control system based on the web frontend would be a horrible mistake, (for the same reasons that Keith mentioned in his blog posting---the web frontend is one of the easiest things to change, so it doesn't have much bearing on the decision). That said, I took a look to see what subversion is using. I found the following page: http://svn.collab.net/viewvc/svn/ And I think it presents the completely wrong default view. If I'd like to casually browse a project's source code history, the first thing I'd be interested in knowing is "what's been going on?". With viewvc all I can see is the commit message from the latest commit to any particular directory or file. That per-file basis was expected in CVS-based tools do to the fundamental broken-ness of the CVS model, but it's really odd to see it in anything developed since. It provides a very random set of commit messages that largely have no relationship to each other. Compare that to what gitweb provides. For example, here's the default view of the cairo project in gitweb: http://gitweb.freedesktop.org/?p=cairo This gives a project-wide log of recent commits. From those it's pretty obvious what has been happening in cairo lately, (I've been whacking on the performance test suite in "perf" and Vladimir has been doing some work on the win32 backend). Meanwhile, a per-file view is still available in one-click by clicking on the tree link: http://gitweb.freedesktop.org/?p=cairo;a=tree [I notice that this view is rather empty and perhaps could benefit from a "latest change" message on each line as viewvc has, (that'd still give a random smattering of messages, but it's perhaps better than empty space). The important part is not to provide only the random smattering of messages and not the project-wide log.] Plus, this per-file view is a heck of a lot more useful than what I could find in viewvc, as I can view the history of changes at any level. For example, what if a user only cares about the changes for some niche piece of cairo, like the BeOS backend, say, there's an easy way to get the history of just that piece of the tree: http://gitweb.freedesktop.org/?p=cairo;a=history;f=src/cairo-beos-surface.cpp The same thing works for viewing any directory, too, not just a file. What's been happening to the test suite in "test", for example: http://gitweb.freedesktop.org/?p=cairo;a=history;f=test And I like the fact that if I explore the history to any given point I can drill-down and view the state of any file in the tree at that point. It looks like a lot of the same information is available in viewvc but through a "query revision history" form where one can type in sub-directories or date ranges rather than being able to browse to them. But again, the web frontends are a really minor piece of the puzzle. And in spite of anything good I said about gitweb here, I think it totally sucks compared to what one can easily do with tools like "git log" and "gitk". Things like: Show me new changes in "trunk" since "branch" split off: git log branch..trunk As above, but with patch content in addition to commit messages: git log -p branch..trunk As above, but only the changes affecting some/dir: git log -p branch..trunk -- some/dir As above, but with a graphical view: gitk branch..trunk -- some/dir Show me a graphical view of all branches: gitk --all I'm afraid that list doesn't capture the functionality very well, but please give commands like that a try sometime if you can get the chance, (particularly if you can do it on a collection of code that you're familiar with). Functionality like this would definitely be part of my short list of things needed in a version-control system. A lot of people focus the discussion on the UI for creating new commits, and forget about the importance of the UI for exploring that history. Here's a thought experiment on that front. Take an operation like "svn blame" and think about the bigger context in which it is used. What is the whole task that is being performed? What operations are performed before and after? For example, let's assume the scenario is "Given a random snippet of code, find the commit information (author and commit message) that introduced that code". So with subversion the operations might be: grep snippet * # map snippet to filename svn blame filename # map file lines to revision IDs | less # / to find snippet in blame output and ID svn log -rID # view commit info Given the same scenario, what I would most likely do with git is: git log -p # display full project history, use / to # find snippet and read nearby commit info This may seem like an awfully big hammer for a very small problem, but the truth is that this really is fast enough that it's what I end up using. Of course, if a single directory or filename is known, then it could go even faster: git log -p -- filename But the point is that this kind of history exploration is fundamentally more useful than something like "blame". This approach with git will work just fine even if the snippet of interest no longer appears in the current code. And git is designed to be able to allow the tracking of code as it gets copied from one file to the next, (talking about partial code movement, not whole-file copy or rename). For a long time that kind of code exploration has just been missing UI, but Junio has added that to git quite recently---and it really was just a little bit of UI. Imagine trying to retrofit any existing system to be able to support partial-file copy for history exploration like this, and then imagine how well it might perform. -Carl
Attachment:
pgp8TqMsPWXMz.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
