Sorry, that did come across as a bit defensive. However, I think if you read the whole article carefully it explains that after doing a git pull, and git refusing to merge because of outstanding changes you then have a chance to either 'revert, commit, or stash'.
That is exactly the behaviour I expect from git, and exactly what broke down in this case.
I'm not sure where you get the idea that I'm not committing early?
If it was the comment saying '3 days of straight hacking' then I apologise for my prose being unclear. I was only bringing that up because my first assumption was that after 3 days of hacking I was tired and assumed it was indeed my fault.
It was a couple of hours worth of code that needed committing.
And doing a pull, which is meant to safely pull in unrelated changes, to test some things before committing, especially when it was a very simple change on head, is completely reasonable.
I'm not ignorant about the many ways in which git can be used, the post wasn't even particularly blame placing. Tools have bugs, shit happens. Most of the post was tracking down the bug, which is much more useful. Thankfully it was already fixed, so I didn't need to fix it myself.
Yeah, HFS+ is a nasty beast. In this case not the culprit, firstly because the first thing I do when getting a new MacBook is reformatting as case-sensitive, and secondly, because it was just a directory rename (e.g: ./foo/ to ./bar/).
Yeha, I wouldn't blame a tool for not dealing with the brain-dead almost case-sensitive HFS+ filesystem.
Exactly, in fact it normally does. git pull is actually really useful for enforcing this most of the time. If you inadvertently do a 'git pull' before doing a commit, and you have any overlapping changes, then git aborts the merge. This is why 'git pull' is generally a safe operation.
They were obviously saved. I was simply pulling before committing, which is a supported work flow of the tool. I don't think I ever said I went days without committing.
Sure, I would agree with that, but in this case I already knew what the one commit I was pulling did. And the fetch,diff, merge wouldn't have helped. The file that was destroyed wasn't changed in the commit that was fetched.
Just to point out that fetch + merge would have caused the same problem. In this case it was a small team, with advance knowledge of what the commit was, so no need to inspect.
But, in any case doing the fetch would have shown that the file was not modified in the fetched tree, and it would have gone ahead and overwritten my changes (without even listing in the merge log that the file was changed).
FWIW, I agree that fetch + (merge | rebase) is in general the best way to go, but I think there is a case when you a pulling in a simple fix from head where doing a pull is legitimate.
After all the documentation says this is a safe operation:
"If any of the remote changes overlap with local uncommitted changes, the merge will be automatically cancelled and the work tree untouched" (from git pull --help).
If this isn't meant to be considered a safe operation git pull should abort if there are any changes to the working directory.
No, you don't interpret correctly. It was not 3 days of uncommitted changes, it was committing some changes after hacking for three days.
Completely different thing. The 3 days was relevant because I was tired and my first assumption is that I had done something wrong. It turns out there was a nasty bug.
Also, I don't think my workflow is that broken:
"Linus often performs patch applications and merges in a dirty work tree with a clean index."
If I am pulling down some unrelated changes, it is not unreasonable to do that. That is one of the features that git provides.
I know perfectly well how to use git, in a number of different work flows, and I use whichever is most appropriate for the given project at the given time.
Also, I don't think my post was complaining. It wasn't 'OMG git is the worst, I'm never using it again', it was an analysis of a particular nasty corner case in git.
http://agilezen.com/ is very close, and actually has a bunch of other useful features too. Although I've got to say that trello is a lot slicker than agilezen.
The rental market in the inner suburbs of Sydney is pretty expensive. It certainly helps to have employment and real estate agents will often ask for some kind of employment reference.
I don't know of any impediments for non-citizens in terms of renting. I've employed people on working holiday visas, short-stay business visa, permanent residency and citizens, and they all seem to be able to find rental accommodation in the inner suburbs of Sydney without too much problem. I've usually provided an employment reference either verbally or on paper.
The way in which the failed product was handled is impressive, but I'm left wondering if there are any more details on the approach that failed?
Sharing why a given approach doesn't work could save others with the same technical idea from wasting time and money trying to turn the same idea into a product.
That is exactly the behaviour I expect from git, and exactly what broke down in this case.