I am gay.
That doesn’t really count as coming out though, if I am anything it’s openly gay. In fact a friend once joked that I manage to include a reference to my sexuality in every blog post or e-mail I write, and that every Twitter post of mine ends in “still gay”.
Maybe he’s right, but if it is, it’s probably subconsciously deliberate.
I confidently predict that there will be no surprise coming out statements this year from anybody in the public eye. Not even from those who don’t exactly do a good job of hiding it, yet deny it every time they are asked. You know who they are.
I think that’s quite sad.
I strongly believe that is the duty of those in the public eye to be open about their sexuality.
Firstly from a positive point of view, everybody needs role models. A young man or woman coming terms to their own sexuality will be able to do much easier knowing that there are public figures they respect who are comfortable with their own sexuality and open about it.
And from a negative point of view, every public figure who’s denying their sexuality is reinforcing the idea that you should not be comfortable with it and that being open about your sexuality will cause you problems.
Many celebrities, for example, claim that the reason they haven’t come out is because they’re afraid of what it will do to their careers. This is not only ironic, since they’re just perpetuating the problem, but clearly nonsense since there are a number of extremely well known and loved figures who are openly gay.
So this is why I’m open about it.
I want to make sure that any new members of our community who are coming to terms with their own sexuality can be assured that this is not going to cause them a problem.
(Still gay)
]]>Before I do, let me make one thing clear (as if it wasn’t already), I am a gay man.
Mark is a heterosexual man. In his LPC keynote he is accused of sexism because in his keynote he said that making Linux easier to understand would make it easier for him to explain what he does to girls.
Now, let’s pretend for a moment that I’d gave that keynote. Let’s pretend that I’d said that that making Linux easier would make it easier for me to explain what I did to boys.
Would there be this uproar?
Oh they’d be an uproar alright, but it wouldn’t be about sexism – the homophobic right of our community would be throwing their bibles out of their prams with vigour!
But nothing about sexism!
In fact the very people who are currently attacking Mark would be defending me as a gay man for right to say things like that. And if they didn’t I could cheerfully accuse them of homophobia.
And that’s why this bothers me.
If Mark was sexist, than he’s sexist for only being attracted to women and understandably caring what they think of him. That’s not sexism, that’s biology!
Sometimes a spade is just a spade.
Sometimes when a man says that he likes girls, HE LIKES GIRLS!
If your complaint is that he uses “girls” to mean “women” then you need to get (a) in touch with some mystical arbiter of the colloquial English language & (b) a grip.
I suspect this has ended my chances of ever being offered a Keynote (not that I ever have) and that Linux Today will now claim I should resign (I don’t work directly for mdz, but I have a tremendous amount of respect for him) then so be it.
And this is why the outcry bothers me.
]]>There’s been some press coverage of this already, and various comments from different people raising some questions about why Ubuntu is going down this route. Since this was largely my idea, I felt I should try and answer a few of the common ones.
rhgb was the “RedHat Graphical Boot” system they used in RedHat and Fedora until the most recent Fedora releases. It worked by starting an X Window System server and running the splash screen inside that.
This sounds very similar to xsplash, but with one key difference: the X server used by rhgb was shut down when boot finished, and a new X server started for the user to login with.
Instead, xsplash uses the same X server as the login window, and the same X server as your desktop. In fact, it’s started by the GNOME Display Manager while it starts the greeter or auto-logins your desktop alongside.
Plymouth is RedHat’s replacement for rhgb, instead of using an X server it relies on Kernel Mode Setting to provide a framebuffer in the panel’s native resolution and colour depth and draws directly to that. When the X server starts, the X server takes over the framebuffer without requiring a mode switch or a screen clear.
In many ways, Plymouth is simply a reimplementation of our original usplash. Indeed, I found it quite ironic that some people have accused us of “NIH”ing xsplash instead of adopting Plymouth, when technically Plymouth is an “NIH”d usplash.
So really the question as to why we don’t use Plymouth is the same as to why we don’t use usplash. We did actually consider replacing usplash with Plymouth since the implementation is rather cleaner, but Plymouth only supports Kernel Mode Setting drivers whereas usplash has a fall-back SVGA mode (it always had framebuffer support, thus KMS support, due to the Ubuntu PowerPC port).
(or Plymouth, see above)
One of our main goals for Ubuntu is boot performance. For Ubuntu 10.04 (that’s karmic+1) we’re targetting a 10s boot from the boot loader to a fully logged in desktop with idle disks. To boot this fast requires some prioritisation.
We need the X Window System server for just about everything. Until we’ve started the X server, we don’t have a display so can’t even start basic things like the underlying services and agents that run for a user’s login session.
Or, put another way, anything we do during boot that isn’t directly required to start the X server is delaying the boot.
The boot sequence must be setup in such a way that starting the X server is prioritised; once the X server is up, we can begin starting the user’s session (or the login screen session). We can also start all those other system services that weren’t dependencies of the X server.
This pretty much turns the current sequence on its head, where the X server is one of the last things started rather than one of the first.
If we started a splash screen such as usplash before the X server was up, we’d still have to wait for the Kernel Mode Setting driver to be loaded (or hardware to be sufficiently probed to know that we don’t have a Kernel Mode Setting driver for it). This is one of the primary dependencies of the X server too (the other is a mounted, writable filesystem), so in many cases we can start the X server at the same time!
Now, you could suggest that we do start the X server but also start the splash screen as well; and that the splash screen animates while the X server is running and the X server doesn’t paint to the screen until the desktop is logged in or the login screen is ready. Unfortunately this simply doesn’t appear to be possible, the X server “takes over” the framebuffer in such a way that the splash screen simply freezes at that point (we can prevent it clearing the screen). With an early X server start, it would spend more time frozen then it would animating.
This also wouldn’t work for the non-KMS case.
You could also argue that we could load the KMS drivers earlier, in the initramfs for example. While possible, this adds a significant time to the boot time for the extra loading and probing required. If we load the KMS driver in the initramfs, it takes about 8-10s to load the X server; if we load the KMS driver in the full system, it only takes about 6-8s to load the X server. Easy win.
But what if we have to check the filesystem, or enter a decryption passphrase to mount it? That’s why we still have usplash. In those cases we will start usplash to display the progress or request the key. The usplash theme will be themed such that when it finishes, and X starts up, it looks ok frozen for the short time until xsplash replaces it with an identical theme.
Patience, my friend. The 10s target is for Ubuntu 10.04 (karmic+1), not karmic (9.10).
That being said there are a number of updates planned for karmic that will boost the performance quite a bit, especially in terms of starting the X Window System server earlier. These have always been targetted to land between Feature Freeze and Beta, simply because it’s delicate work that needed a lot of testing first and that everyone else’s uploads prior to Feature Freeze kept throwing it off.
Look for a call for testing RSN.
]]>Its detractors will tell you how it takes much longer it takes to program anything in C. They’ll point at how much C code it takes to do something as simple as create a GObject sub-class compared to the equivalent in Python or C#. They’ll also probably complain that everything in C has to be compiled first, which takes even more time up.
No argument would be complete without them pointing out that C has no standard types for strings, let alone linked lists, binary trees, associative arrays, etc. and that you have to spend all that time implementing your own. They’ll probably make a point about how C’s static type system means that even if you have a array type, you need to know in advance what types you’re going to put into it and can’t just mix and match.
Don’t feel tempted at this point to counter with a discussion about how great and flexible pointers are. You’ll receive a lashing about how they’re even more evil than people who talk in the theatre. The rant about the C problems of uninitialised memory, out of bounds pointer errors and segmentation faults is a timeless classic. Especially when they get to the bit about how much time was lost debugging them.
And do you know what?
I simply do not agree with them.
I cannot think of a single project where the majority of time was wasted writing GObject header files compared to the single line of Python I needed. I can think of lots where I’ve sat for hours trying to figure out which class I needed to derive from, or reworking the code after I realised I derived from the wrong class to begin with. The high-level language doesn’t make this any easier.
As to the number of projects where I’ve needed to write a linked list or hash table implementation because C lacked a convenient dynamic array or associative array type like Python? If it takes you any time to write that kind of code, you’re doing it wrong. I’ve spent far more time realising that the structure is a performance bottleneck, and planning on the whiteboard a faster alternative. Neither language helps with this whiteboard time.
And all those pointer issues? This comes down to the tools that you’re using. If you’re writing in a language and not using its development environment properly, then it’s little surprise that you’re not being as efficient in it. gdb, valgrind, gprof and gcov are your friends. Use them well. I’ve spent just as much time dealing with other language-specific issues to make me believe that pointers aren’t any more evil as (for example) monkey patching.
The vast majority of my time on any new project is first of all spent thinking, and on a more mature project its figuring out what I did wrong and how I need to rework it.
Yes, the next biggest use of my time is working out what the best way is to express that. If I’m writing in C, that means I’m deciding whether it needs a linked list, or a hash table, or some other fancy structure. But if I’m writing in Python, believe me I spend just as much time normalising my class structure and coming up with all sorts of insane Pythonic ways of doing things.
If you’ve ever written in Perl and not lost a day or two to optimising your regular expressions, or eliminating code to arrive at the shortest possible expression, you’ve never written in Perl.
Refactoring takes you just as long in Python as it does in C. Just because when you do it to C code you end up setting segfaults doesn’t mean that when you do it to Python code, suddenly your class structures don’t match anymore.
Proponents of test-driven-development, AGILE, LEAN and ANEMIC programming methodologies will probably argue that it’s easier to practice their religion with a high-level language. I’m not buying that either, I’ve managed to write several large software projects in C that have a comprehensive test suite – including testing for allocation failures.
Ah, Rapid Application Development I hear you say? Well, the only people I’ve ever heard say how great RAD is are people who’ve never had to support the software that was written rapidly, or debug issues with it years later. RAD is great when v2 is going to be a complete rewrite, and v3 a complete rewrite again. Very few websites have upgrades without announcing a completely new codebase.
It’s certainly true that it’s faster to mash up some code in a high-level language. I use shell scripts and bits of Perl for this kind of thing all the time, and I frequently even do basic mock-ups or essays in Python. But ultimately it all tends to be throw-away code, that I don’t really ever intend to take seriously or attempt to support later on.
For larger projects, I just don’t see any difference in the time it takes to write.
I’d like to cite an example. The GIT and Bzr revision control systems are about the same age, one of them is written in C and one of them is written in Python. It hasn’t taken them any less time to write the one in Python than it’s taken the others to write the other in C. The one in Python doesn’t have extraordinary features that the one in C lacks.
C# fans would point out how much faster it is to UI code. Really? Then why isn’t Banshee that much dazzingly better than Rhythmbox? Sure they’re different, but there’s nothing there that suggests one language is better than the other.
And do you know what? I trust code written in C far more than I do any higher level language. No, that’s probably not fair. I trust C programmers far more than I do programmers of other languages. If you tell me I have the option of choosing a program or library written in C over one written in Python or C#, I’ll take the C one every time.
]]>I wonder if you’ve heard of a Drabble?
A drabble, simply put, is a story, normally science fiction or fantasy that is exactly one hundred (100) words in length. No more, no less.
Such things were often written in a contest, and so I’d like to propose such a contest.
To participate, all you have to do is write a story in 100 words and post it on your blog.
Here’s my attempt, entitled The Siege.
]]>‘The city, sir! It’s under siege!’
The king put down his goblet and stared at the sergeant.
‘Who is it this time?
‘It can’t be the dwarfs, they can’t reach the ramparts.
‘The trolls just don’t have the stamina.
‘The elves get drunk and wander off singing.
‘The ents are easily dispatched with fire.
‘And as for the orcs, wait long enough and they kill each other.’
‘So who is it? Hmm?’
The sergeant looked sheepish, as the king awaited his answer.
‘It’s our own people, Sir!’
Ah, this was going to be a problem.
And many told me I was an idiot, and that they had no problem; and that I should learn how to use GIT instead of just stabbing at guesses.
Those made me realise what the fundamental difference between myself and them are.
I don’t want to use a revision control system.
It follows that if I don’t want to use one, I certainly don’t want to waste time learning one! I don’t want to use a text editor either, again it’s just something that gets in the way of what I really want to do.
I want to write code, and I want to fix bugs and test the fixes.
Actually, I don’t really want to fix bugs; but it’s one of those things you have to do as a responsible software author and maintainer. Now, I sadly can’t just write code by thinking about it. Even though I use zsh, holding down the TAB key just doesn’t write my code for me, so I have to use a text editor.
And I hate them, especially emacs, which is the text editor I use. I keep hoping that one day Anjuta or something like MonoDevelop will be usable for writing and debugging C – but alas, that day has not yet come. (Incidentally, if a developer would like some constructive criticism from my side, I would be perfectly happy to do give it – just grab me on IRC).
Now I don’t have to use a Revision Control System, unlike a text editor which is somewhat essential, but there are a lot of advantages to using one. In particular, I think I have two primary use cases:
Since I don’t want to use a Revision Control System, it should be as simple and painless to use as possible. I have probably a dozen common actions that I do; so each of these actions should be just one command, with no options or flags to make them do the right thing. For bonus points, these commands should be obvious and ideally have aliases for the similar commands in other systems for easier learning.
Here’s the first set:
We could probably call these get, commit, push and pull. Note that I’m not allowing for any kind of add, move or remove command. Such things are a pain in the neck; my most common preference is just for any changes I’ve made to be committed. This is probably one big reason why GIT and I don’t get on so well; it’s written for somebody else’s use case where the most common use case is committing nothing.
Since I pretend to like other people working on my software, I’ll need a couple of commands for doing that:
I’ve yet to see a revision control system that makes the first one easy, which is sad, because it’s just about the most common operation I do on other people’s branches/repositories/clones; I’d call that review, and then we can call the second one merge.
And then for the last set:
We can call these log, diff and show (though ideally diff and show would be just the same command with a revision range or single revision).
I’ve probably forgotten something important, but in general, those are the operations I try and do with a revision control system. Thus I can create a Revision Control System Hate Index. The more commands, options or flags it takes to do any of these operations, the higher the Hate Index and the more I’ll loathe it.
GIT scores badly, very few of these operations are a simple command. Many require pre-configuration, many require options and flags to do the right thing. And a couple of them are actually multiple commands.
In fact, GIT’s hate index gets increased further, because after a while you realise that most of the top-level commands very rarely do the right thing. Instead, you start to break down the commands to their fundamentals. If you’ve ever found yourself using git fetch you know what I mean.
This means that I have to stop thinking about writing code, and start thinking about using the revision control system and what the best way to accomplish the operation that I want is. This is a fail that only results in hate.
And just for the peanut gallery, I’d like to point out that Bzr has a non-zero Hate Index as well. In fact, there are misfeatures and bugs in Bzr that make my blood boil just as much as GIT, sometimes even more since Bzr actually claims to always try to do what I mean.
You know what would make me happiest? If I had a text editor that took care of revision control for me. Sometimes I wish there was a Linux version of the good old Borland IDE or at least VisualStudio.
]]>In that post, I suggested that the following git command would work:
quest util-linux% git clone --bare . ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git
I wholeheartedly apologise. It turns out that what this command does is make the following local directory: $(pwd)/ssh:/kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git.
Unfortunately this means that normal service of hating git, while still being utterly unable to find any reasonable command to do what I want, will have to resume.
All I want to do is run a command to take the branch I have in my local working tree, and put that on a remote server so that other people can get at it.
Failing that, I want sharks with frikkin’ laser beams on their foreheads!
Is either so much to ask?
]]>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 collaborationyou 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.
]]>Let’s take the most mind-numbingly trivial of operations, I want to put a branch I have somewhere so somebody else can get it. That’s the whole point of distributed revision-control, collaboration.
That’s too fundamental to be covered in the git tutorial, after all, it wouldn’t be fun if it were that easy.
Happily, git has built in manual pages. And knowing a few other revision control systems, we can guess that the command might be push. And indeed, there’s a push command:
push Update remote refs along with associated objects
Maybe this isn’t going to be so hard after all, a quick git push –help and we’ll be laughing.
DESCRIPTION
Updates remote refs using local refs, while sending objects necessary
to complete the given refs.
Ok, err, not quite sure what that means; but it sounds like it’s doing something over there with what I have here. Probably the tool I want.
You can make interesting things happen to a repository every time you
push into it, by setting up hooks there. See documentation for git-
receive-pack(1).
I’m not sure I want to know about making interesting things happen right now, I’ll just settle for some boring making-things-public.
OPTIONS
<repository>
The “remote” repository that is destination of a push operation.
See the section GIT URLS below.
Aha! Now we’re getting somewhere. I give it an argument saying where I want to push to, that all makes perfect sense. A quick skip down to the URLs bit tells me I can use ssh, which is what I want.
There’s one other mandatory argument though.
<refspec>…
The canonical format of a <refspec> parameter is +?<src>:<dst>;
that is, an optional plus +, followed by the source ref, followed
by a colon :, followed by the destination ref.
Err?
*blink*
Whuuuuh?
My brain seems to have fallen out of my head, let me pop it back in and read that paragraph again.
<refspec>…
The canonical format of a <refspec> parameter is +?<src>:<dst>;
that is, an optional plus +, followed by the source ref, followed
by a colon :, followed by the destination ref.
It didn’t get any better the second time.
Some faffing around, guess-work and cargo culting what other people do seems to suggest it wants the branch name there. Well, why didn’t it say so?
Ok, that should be easy then.
quest util-linux% git push ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git ubuntu fatal: '/srv/kernel.ubuntu.com/git/scott/util-linux.git': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly
I’ve had a few ex-boyfriends hang up on me before, and they were gits too.
There’s nothing in the manual page about this.
There’s nothing in the tutorial.
What the holy crap is going on?
Turns out, you need to create the other side first. Why the buggering bollocks can it not to that for you?
So, let’s try that. There’s some clues about this in the git init manual page, but I have to be honest and I begged for help (and mercy) at this point:
quest util-linux% ssh zinc zinc scott% cd /srv/kernel.ubuntu.com/git/scott zinc scott% GIT_DIR=util-linux.git git init Initialized empty Git repository in /srv/kernel.ubuntu.com/git/scott/util-linux.git/ zinc scott% exit quest util-linux% git remote add zinc ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott quest util-linux% git push zinc ubuntu Counting objects: 10652, done. Compressing objects: 100% (2545/2545), done. Writing objects: 100% (10652/10652), 19.10 MiB | 12192 KiB/s, done. Total 10652 (delta 8075), reused 10534 (delta 8013) To ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git * [new branch] ubuntu -> ubuntu
Hurrah! At last!
No.
Not at all.
Firstly, pushing to a remote branch doesn’t make it visible in anything like gitweb. You have to do enable that.
quest util-linux% ssh zinc zinc scott% cd /srv/kernel.ubuntu.com/git/scott/util-linux.git zinc util-linux.git% chmod +x hooks/post-update zinc util-linux.git% git update-server-info zinc util-linux.git% exit
Ok, now does it work?
No.
Looks all ok, but if somebody tries and checks that out:
wing-commander scott% git clone git://kernel.ubuntu.com/git/scott/util-linux.git Initialized empty Git repository in /home/scott/util-linux/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout.
What the hell?
How can a push command succeed while leaving an utterly useless branch?
Don’t bother trying to find this one in the manuals:
quest util-linux% ssh zinc zinc scott% cd /srv/kernel.ubuntu.com/git/scott/util-linux.git zinc util-linux.git% rm HEAD zinc util-linux.git% ln -s refs/heads/ubuntu HEAD zinc util-linux.git% exit
Now it works.
In all that is holy, what, the, fuck.
Seriously?
My quote of the day:
“Git is hard to use if you are not used to its workflow.”
No.
Git is hard to use.
Here’s what I wanted to do:
quest util-linux% revision-control-system push ssh://host/path/somewhere
If it takes anything more than that, it’s fucked.
]]>