Scott James Remnant

Jason Clinton replied to my virtiolic rant about GIT with a well researched and thought out reply.  Sorry, that’s not what I mean.  He replied to my rant against a piece of technology with a personal attack.

I feel that there’s a few points that I need to reply to.

Romeo Tango Foxtrot Mike

I did, in fact, the vast majority of my post was excerpts from the Foxtrot Mike.  It was the Foxtrot Mike that was half of the problem.

and because the company you work for has a horse in this race and they can do no wrong

What does this having anything to do with anything?  The company I work for develops many pieces of software, and a quick bit of searching will find people who work for the same company (including myself) complaining just as loudly about them.

Sometimes, sadly, it seems that people in the open source world are unable to separate other people from the companies that they work for.  Ironic, given the high turnover, and frequent moves between the different companies that most people seem to go through.

I am not Canonical.  I am not on the Bazaar team.  I have been involved in open source since long before I joined Canonical, and I will almost certainly be involved long after I leave Canonical.

Most importantly, I am able to hold my own opinions, and I am able to form those opinions without influence from my employers.

If you don’t believe me, just go back a couple of years and look at some of my rants about Arch, and the first Bazaar.  Ask for a copy of my book, “Arch is easy, and other lies the developers may have told you.” It has a cool cover.

GIT reminds me a lot of Arch.

My personal opinion about this is that Arch (and now GIT) is the first distributed revision control system that people try, and then they get it.  They understand why distributed revision control is so awesome, and they attribute this awesomeness to Arch (and now GIT) rather than realising that it’s an inherent property of any such system.  The learning curve is pretty damned steep, so there’s a lot of investment to learn Arch (and now GIT) and once people have made an investment in something, and received an epiphany as an award, they become very attached to it and very aggressive about attacks on it.

and because you can’t be bothered to look up what you want to do first

Again, it should be clear from the post that I had spent a very long time trying to look up what I needed to do and found no help.

From the very same Git Tutorial that you were about to link to in a giant section titled Using git for collaboration you could, you know, look at the command you think you might want:

Have you actually read that?  I have, yesterday as it happens.  All of the examples are with bob and alice working on the same machine, it makes a brief reference to the two being on different machines but then assumes that bob can access alice’s workstation.

Utterly useless.

And since you’re a very smart person with a history of working with VCS’s and a resume a mile long in the FOSS community, you know that that’s a giant red flag that you’re about to force the tool you’re using in a mode that is not distributed.

And as you can clearly see, I was trying not to do so.  I was simply trying to push changes from my workstation to a server from which alice, err sorry, lamont could pull them.  If I am picking the wrong commands because of familiarity with other systems, then frankly GIT is being perverse in deliberately using commands in a different way.  Even BitKeeper used push for “make your changes public”.

You say that I’m using the wrong command?  Well, let’s try and figure out from first principles what command I actually want.  git help should tell us:

The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find the change that introduced a bug by binary search
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and merge with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object signed with GPG

Any of those strike you as doing what I want?  I imagine that getting changes from your workstation to a web or git server is a sufficiently commonly used command, after all, even the kernel developers all publish their branches on master.kernel.org.

Well, it’s clearly not add, or fetch.  merge? pull? no. reset? status? no.

You know, reading that, I really might think that the right command is push.

The git(1) manual page gives even more commands, one of them looks really appropriate:

git-send-pack(1)
Push objects over git protocol to another repository.

The manual page on this instantly refers us back to push.

DESCRIPTION
Usually you would want to use git-push, which is a higher-level wrapper
of this command, instead. See git-push(1).

If push really isn’t the right command, perhaps the Foxtrot Mike could stop referring to it everywhere?

Now, it happens that I received some helpful replies as well.  You clearly know the right command, and even manage to mention it, but not in any kind of helpful way.  Another kinder soul was much more helpful.

clone is the right command, it can take two arguments and the first argument can be “.” while the second can be a remote URL:

quest util-linux% git clone --bare . ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git

was what I actually wanted.  Curiously nobody in the #git channel seemed to know about this when I was asking for help.

Users coming from other revision control systems will probably equate clone to branch, or checkout or some other similar operation.  It probably won’t occur to them that they can reverse the arguments.  This should definitely be prominently documented.

And no, the GIT tutorial never gives this example.  It’s always clone remote to local.

Random aside, I discovered that bzr supports bzr branch local remote as well; neat.

Someone else tried to be helpful, but ended up simply being amusing.  They suggested that I use git format-patch to extract my patches and then send them by e-mail.

Can I just say that if your revision control system is so bad for collaboration that patches must still be sent by e-mail, then something is deeply, deeply wrong.

To finish up, in a comment on your own blog post you say:

All the documentation in the world won’t help if even smart people like Scott decide not to read it and demand that git work exactly like bzr does. Which is exactly what happened here. Again.

A quick bit of checking would show that the example I gave wouldn’t work with bzr either.  Bzr needs a silly “bzr+” on the front of the URL, there’s a lot of fail there too.