On Wed, 18 Apr 2007, Steve Frécinaux wrote: > On Wed, 2007-04-18 at 16:55 -0400, Daniel Barkalow wrote: > > > 1. If your organization has a bunch of different projects, and there's > > some central location holding the upstream that people regularly pull > > from, there's no way to abbreviate this parent directory. (Equivalent > > of CVSROOT environment variable) > > > > I.e., we've got file-server:/var/git/<project>.git at my work, with > > dozens of projects, and you have to give the whole thing to git clone > > each time. > > export GITROOT=file-server:/var/git > git-clone $GITROOT/project.git > > git doesn't enforce that but you can still do it with some shell karma. > > BTW as far as I know no other scm than CVS provides this kind of thing, > and it's more often seen as a defect than an advantage. For instance, a > novice which had to checkout a CVS project from sourceforge and another > from cvs.gnome.org and another from... wasn't helped at all. SVN has it > much simpler (understandable) by just providing a URL for checkouts. It's counterproductive to require both a "root" and a "module" if there isn't any sort of commonality, but it's useful to be able to have a default. Besides CVS, arch also has something of the sort. I haven't used anything else in a corporate setting (where most of the things you check out are from the same place). > > 2. There's no easy way to tell that you've made commits that you haven't > > pushed upstream. In fact, it's impossible to tell when disconnected > > whether you've pushed everything. This needs some command to report it, > > and also for push to update the fetch sides of remote heads it updates. > > I surprised myself doing so: > git-push $remote > git-fetch $remote > given that the remote in question pushes master, and pulls into $remote. > Maybe such a thing (in the idea) should be done implicitely. I mentioned it a while back, but never got around to implementing it, mostly because it's all in shell scripts (or was). -Daniel *This .sig left intentionally blank*