{"thread":{"id":"7728","subject":"Things that surprise naive users","startedAt":"2007-04-18T20:55:09Z","lastAt":"2007-04-18T23:57:46Z","messageCount":4,"participants":["Daniel Barkalow","Steve Frécinaux","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39823","messageId":"Pine.LNX.4.64.0704181503080.27922@iabervon.org","threadId":"7728","inReplyTo":null,"subject":"Things that surprise naive users","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-18T20:55:09Z","receivedAt":"2007-04-18T20:55:09Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Here's my collection of things that I think block the adoption of git by \nnovices. They should be easy to fix, but non-trivial shell makes my eyes \nglaze over. I think that, if these were fixed, someone just sitting down \nwith git in a corporate environment with stuff set up in advance by the IT \ndepartment would succeed in everything they thought to try. (Once they're \nusing the obvious stuff, they can exchange advanced features with each \nother.)\n\n1. If your organization has a bunch of different projects, and there's \n   some central location holding the upstream that people regularly pull \n   from, there's no way to abbreviate this parent directory. (Equivalent \n   of CVSROOT environment variable)\n\n   I.e., we've got file-server:/var/git/<project>.git at my work, with \n   dozens of projects, and you have to give the whole thing to git clone \n   each time. It'd be nice to have a global config option such that, if \n   the argument to git-clone doesn't have any /, it prepends the standard \n   default. (Also an environment variable for the same purpose on a shell\n   session scope.)\n\n2. There's no easy way to tell that you've made commits that you haven't \n   pushed upstream. In fact, it's impossible to tell when disconnected \n   whether you've pushed everything. This needs some command to report it,\n   and also for push to update the fetch sides of remote heads it updates.\n\n3. You can't create a new repository by pushing, even if you could \n   actually create the repository. Obviously, this will be blocked by \n   policy more often than pushing in general would be, but it's not\n   always blocked. It's also harder than it should be to turn a repository \n   created locally into a repository identical in configuration to a clone\n   of a newly-created remote repository. \n\n4. Creating new branches off of existing branches/remotes doesn't \n   configure the new branches in the obvious way (i.e., such that the \n   default update action matches the create action).\n\n5. Still too much output from core makes it to front end users, \n   particularly on successful recursive merge. \"git-pull\" should say:\n   fetching: (bunch of progress)\n   updating \"origin\" (bunch of refs)\n   merging \"origin\" <ref>\n    failed: afraid local changes might be messed up in <files>\n   or\n    manual merge needed in <files>\n   or\n    success: merge made automatically\n   or\n    success: no local changes needed merging\n\n   There's still a lot of \"I tried this, but it didn't work, but the next \n   thing did work.\" People are used to programs where, if something fails,\n   it is followed by a bunch of meaningless messages, and only the first\n   failure output matters and needs to be corrected. (Mostly compilers, \n   but also kernel oopses, other system errors, etc.)\n\n6. I bet people would have an easier time with remote configuration of \n   repositories (when the user is actually able to configure the \n   repository, of course). I.e., if I've set up a remote repository, and\n   I have a local clone, I should be able to turn on cvsserver support\n   with \"git remote-config gitcvs.enabled true\" in the local clone, if\n   (and only if), I could just go there and use git config.\n\n7. I think there's more useful stuff possible for remote operations on\n   upstream repositories, but that's less obvious.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"39828","messageId":"1176930970.7733.9.camel@mejai","threadId":"7728","inReplyTo":"Pine.LNX.4.64.0704181503080.27922@iabervon.org","subject":"Re: Things that surprise naive users","fromName":"Steve Frécinaux","fromEmail":"nudrema@gmail.com","sentAt":"2007-04-18T21:16:10Z","receivedAt":"2007-04-18T21:16:10Z","isPatch":false,"sender":{"key":"nudrema@gmail.com","avatar":null},"body":"On Wed, 2007-04-18 at 16:55 -0400, Daniel Barkalow wrote:\n\n> 1. If your organization has a bunch of different projects, and there's \n>    some central location holding the upstream that people regularly pull \n>    from, there's no way to abbreviate this parent directory. (Equivalent \n>    of CVSROOT environment variable)\n> \n>    I.e., we've got file-server:/var/git/<project>.git at my work, with \n>    dozens of projects, and you have to give the whole thing to git clone \n>    each time. \n\nexport GITROOT=file-server:/var/git\ngit-clone $GITROOT/project.git\n\ngit doesn't enforce that but you can still do it with some shell karma.\n\nBTW as far as I know no other scm than CVS provides this kind of thing,\nand it's more often seen as a defect than an advantage. For instance, a\nnovice which had to checkout a CVS project from sourceforge and another\nfrom cvs.gnome.org and another from... wasn't helped at all. SVN has it\nmuch simpler (understandable) by just providing a URL for checkouts.\n\n>    It'd be nice to have a global config option such that, if \n>    the argument to git-clone doesn't have any /, it prepends the standard \n>    default. (Also an environment variable for the same purpose on a shell\n>    session scope.)\n\nBut this is also a good idea ;-)\n\n> 2. There's no easy way to tell that you've made commits that you haven't \n>    pushed upstream. In fact, it's impossible to tell when disconnected \n>    whether you've pushed everything. This needs some command to report it,\n>    and also for push to update the fetch sides of remote heads it updates.\n\nI surprised myself doing so:\n  git-push $remote\n  git-fetch $remote\ngiven that the remote in question pushes master, and pulls into $remote.\nMaybe such a thing (in the idea) should be done implicitely.\n"},{"id":"39835","messageId":"Pine.LNX.4.64.0704181746410.27922@iabervon.org","threadId":"7728","inReplyTo":"1176930970.7733.9.camel@mejai","subject":"Re: Things that surprise naive users","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-04-18T22:28:21Z","receivedAt":"2007-04-18T22:28:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 18 Apr 2007, Steve Fr�cinaux wrote:\n\n> On Wed, 2007-04-18 at 16:55 -0400, Daniel Barkalow wrote:\n> \n> > 1. If your organization has a bunch of different projects, and there's \n> >    some central location holding the upstream that people regularly pull \n> >    from, there's no way to abbreviate this parent directory. (Equivalent \n> >    of CVSROOT environment variable)\n> > \n> >    I.e., we've got file-server:/var/git/<project>.git at my work, with \n> >    dozens of projects, and you have to give the whole thing to git clone \n> >    each time. \n> \n> export GITROOT=file-server:/var/git\n> git-clone $GITROOT/project.git\n> \n> git doesn't enforce that but you can still do it with some shell karma.\n> \n> BTW as far as I know no other scm than CVS provides this kind of thing,\n> and it's more often seen as a defect than an advantage. For instance, a\n> novice which had to checkout a CVS project from sourceforge and another\n> from cvs.gnome.org and another from... wasn't helped at all. SVN has it\n> much simpler (understandable) by just providing a URL for checkouts.\n\nIt's counterproductive to require both a \"root\" and a \"module\" if there \nisn't any sort of commonality, but it's useful to be able to have a \ndefault. Besides CVS, arch also has something of the sort. I haven't used \nanything else in a corporate setting (where most of the things you check \nout are from the same place).\n\n> > 2. There's no easy way to tell that you've made commits that you haven't \n> >    pushed upstream. In fact, it's impossible to tell when disconnected \n> >    whether you've pushed everything. This needs some command to report it,\n> >    and also for push to update the fetch sides of remote heads it updates.\n> \n> I surprised myself doing so:\n>   git-push $remote\n>   git-fetch $remote\n> given that the remote in question pushes master, and pulls into $remote.\n> Maybe such a thing (in the idea) should be done implicitely.\n\nI mentioned it a while back, but never got around to implementing it, \nmostly because it's all in shell scripts (or was).\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"39844","messageId":"46a038f90704181657i540e8468xf2809e81e5cf7ac5@mail.gmail.com","threadId":"7728","inReplyTo":"Pine.LNX.4.64.0704181503080.27922@iabervon.org","subject":"Re: Things that surprise naive users","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-18T23:57:46Z","receivedAt":"2007-04-18T23:57:46Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/19/07, Daniel Barkalow <barkalow@iabervon.org> wrote:\n> 2. There's no easy way to tell that you've made commits that you haven't\n>    pushed upstream. In fact, it's impossible to tell when disconnected\n>    whether you've pushed everything. This needs some command to report it,\n>    and also for push to update the fetch sides of remote heads it updates.\n\nCogito does this (push updating the refs), and I like it. I think it's\nworth doing. Then git-branch -v could flag pending-to-push local\nbranches.\n\n> 3. You can't create a new repository by pushing, even if you could\n>    actually create the repository. Obviously, this will be blocked by\n>    policy more often than pushing in general would be, but it's not\n>    always blocked. It's also harder than it should be to turn a repository\n>    created locally into a repository identical in configuration to a clone\n>    of a newly-created remote repository.\n\nIt's not too hard to do a\n\n      git-publish git+ssh://host/path/to/repo.git\n\nthat just does a git init or maybe rsyncs out.\n\n> 4. Creating new branches off of existing branches/remotes doesn't\n>    configure the new branches in the obvious way (i.e., such that the\n>    default update action matches the create action).\n\nJunio was pointing out recently that there's an option for that -\npull.automerge I think - that you can set in your /etc/gitconfig. Or\nyou can say --track\n\ncheers,\n\n\n\nmartin\n"}]}