Re: Things that surprise naive users

From: Steve Frécinaux <nudrema@gmail.com>
Date: Apr 18, 2007, 21:16 UTC
Message-ID: <1176930970.7733.9.camel@mejai>
In-Reply-To: <Pine.LNX.4.64.0704181503080.27922@iabervon.org>

On Wed, 2007-04-18 at 16:55 -0400, Daniel Barkalow wrote:

Show 8 quoted lines

> 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'd be nice to have a global config option such that, if 
>    the argument to git-clone doesn't have any /, it prepends the standard 
>    default. (Also an environment variable for the same purpose on a shell
>    session scope.)

But this is also a good idea ;-)

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