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.
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 don't think its reasonable. 100% of posters here don't think its reasonable. You just demonstrated why its not reasonable. Yet you say its reasonable.
Here's my rule for version control: if an operation can go wrong, it will go wrong.
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.
... which git failed to do properly. So the git-pull man page is clear that it won't clobber your uncommitted changes. Except in the (buggy) case when it will.
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.
"Safe" or otherwise, it's (IMO) never a good idea to merge uncommitted files.
You're losing history that way: If the merge doesn't actually work, then you've got a screwed up file and no way to roll it back.
It's one of the great strengths of git that you can commit files even if someone else has changed them. It's a bad idea to merge when you have anything significant checked out (I'll leave temporary debugging changes checked out, or very small changes, but that's it). Heck, it's a good idea to check in every few hours, to track changes your making.
Agree 100% I've seen this same type of issue occur in mercurial when people were doing what I call "all or nothing merging". You should not be merging unless you can get to the precise pre-merge state.
the real "mistake" here was not doing 'pull' it was doing 'pull' while having uncommitted changes in the working directory. I'd commit or stash before the pull/
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.
You referenced that article to claim that Linus does what you did. But that article is quite clear that Linus does not do what you do: He either reverts, commits or stashes first. Had you done that you would not have had your problem.
Its one thing to fuck up and get panned on HN. Its another to go looking for justification that you are right. Its yet another to select a single quote from an article to justify your position when the entirety of the article refutes your claim.
You did a great public service by calling attention to this problem (the problem being not using git properly - nobody is going to hold that against you). Don't ruin it now by getting all defensive.
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.
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.
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.