Things that surprise naive users

Things that surprise naive users

[Daniel Barkalow]

Here's my collection of things that I think block the adoption of git by 
novices. They should be easy to fix, but non-trivial shell makes my eyes 
glaze over. I think that, if these were fixed, someone just sitting down 
with git in a corporate environment with stuff set up in advance by the IT 
department would succeed in everything they thought to try. (Once they're 
using the obvious stuff, they can exchange advanced features with each 
other.)

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

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.

3. You can't create a new repository by pushing, even if you could 
   actually create the repository. Obviously, this will be blocked by 
   policy more often than pushing in general would be, but it's not
   always blocked. It's also harder than it should be to turn a repository 
   created locally into a repository identical in configuration to a clone
   of a newly-created remote repository. 

4. Creating new branches off of existing branches/remotes doesn't 
   configure the new branches in the obvious way (i.e., such that the 
   default update action matches the create action).

5. Still too much output from core makes it to front end users, 
   particularly on successful recursive merge. "git-pull" should say:
   fetching: (bunch of progress)
   updating "origin" (bunch of refs)
   merging "origin" <ref>
    failed: afraid local changes might be messed up in <files>
   or
    manual merge needed in <files>
   or
    success: merge made automatically
   or
    success: no local changes needed merging

   There's still a lot of "I tried this, but it didn't work, but the next 
   thing did work." People are used to programs where, if something fails,
   it is followed by a bunch of meaningless messages, and only the first
   failure output matters and needs to be corrected. (Mostly compilers, 
   but also kernel oopses, other system errors, etc.)

6. I bet people would have an easier time with remote configuration of 
   repositories (when the user is actually able to configure the 
   repository, of course). I.e., if I've set up a remote repository, and
   I have a local clone, I should be able to turn on cvsserver support
   with "git remote-config gitcvs.enabled true" in the local clone, if
   (and only if), I could just go there and use git config.

7. I think there's more useful stuff possible for remote operations on
   upstream repositories, but that's less obvious.

	-Daniel
*This .sig left intentionally blank*

Re: Things that surprise naive users

[Steve Frécinaux]

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

Re: Things that surprise naive users

[Daniel Barkalow]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=X-UNKNOWN, Size: 2143 bytes --]

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*

Re: Things that surprise naive users

[Martin Langhoff]

On 4/19/07, Daniel Barkalow <barkalow@iabervon.org> wrote:
> 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.

Cogito does this (push updating the refs), and I like it. I think it's
worth doing. Then git-branch -v could flag pending-to-push local
branches.

> 3. You can't create a new repository by pushing, even if you could
>    actually create the repository. Obviously, this will be blocked by
>    policy more often than pushing in general would be, but it's not
>    always blocked. It's also harder than it should be to turn a repository
>    created locally into a repository identical in configuration to a clone
>    of a newly-created remote repository.

It's not too hard to do a

      git-publish git+ssh://host/path/to/repo.git

that just does a git init or maybe rsyncs out.

> 4. Creating new branches off of existing branches/remotes doesn't
>    configure the new branches in the obvious way (i.e., such that the
>    default update action matches the create action).

Junio was pointing out recently that there's an option for that -
pull.automerge I think - that you can set in your /etc/gitconfig. Or
you can say --track

cheers,



martin