Unpleasant software discovery of the day
Git is a lovely version control system, but for some strange reason it occasionally decides that two copies of the same source are mysteriously out of date with respect to each other and it thus won’t accept pushes from one to the other unless I first pull a (bogus) changeset from the other, then revert it out.
A few days ago, the horrible thing updated one file out of a changeset, but left all of the other files unchanged? And this was the 1.2.8 discount release, which ended up being published as 1.2.7 with the 1.2.8 VERSION file?
Siiiiiiiiigh.
I’d update my copy of git to v1.6, except it was more of a pain than I liked to wrap 1.5.2.2 with configure.sh and port it to Unices that are more than six months old, and, given the Open Source®©™ foundations of the product, I strongly suspect it’s not gotten any easier to port.
Comments
Rebasing is where git pulls out a bunch of commits and lets you remake them into One Big commit, right? I don’t think that’s what happened, because I don’t do that; the messy daily commit messages are part of my development history, and I don’t want to lose that. (I seem to be a outlier in regards to commit history; when I was working for b*tm*v*r one of the constant complaints was that I never “cleaned up” my work before pushing it back into the mainline, and these days I’ve actually gotten into arguments with Open Source®©™ fanboys who are convinced that I’m not using git properly unless I rebase the fuck out of my sccs trees.)
Alas, there’s not much payoff in going out to get an irc client so I can try to get support for an older version of git (1.5.2.2, and the latest is 1.6.something? If my experience in software development – both freeware and payware – is any indication, the very first suggestion would be “upgrade to 1.6.x and see if it keeps happening” It took about 4 days to wrap configure.sh around git and port it to SLS Linux the first time around; that’s quite a bit of work when something breaks once, and can be worked around by discarding the offending sccs tree and recloning.)
Oh, and in regards to “PEBCAK” ? The unpleasant Open Source®™© attitude of “our software is a Paragon Of Software Engineering and it’s YOUR FAULT™ if you don’t understand it because All You Have To Do Is Read The Source Code And Upgrade To The Exact Same Version Of The Operating System That We Use!” is one of the things I find most offputting about the whole software engineering racket. Git succeeds on its own merits, and understandability is not one of them. Even B*tk**p*r, which doesn’t have very good documentation at all, has much better documentation than Git has; if I hadn’t have spent several years working with bk, I strongly doubt I would have ever managed to get to the point where I could have figured out the exceedingly rudimentary documentation (and mindfields) of this system.
Smugly blaming the user for the defects in the tool? Well, that’s probably easier than writing proper documentation, but it’s not the sort of thing that will attract users who have better things to do than act as nursemaids for flakey code.
Comments are closed
What probably happened is that the history diverged (for example branch got rebased) and whet you have on one computer is not stright superset of what you have on other computer. It is so called ‘non fast-forward’ case. You can always force push or fetch.
Without more details I guess that it is the cause of PEBCAK, or not enough knowledge of git (which, admittedly, has its own idiosyncrazies), not a bug/misfeature of git.
BTW. if you had brought this issue to git mailing list, or to #git IRC channel on FreeNode, you would probably got detailed explanation and help.