Plumbing Life's Depths - GIT is a PITA (Stupid, stupid, stupid source code control...)

ARGH! Spent the whole day working on OLPCGames. Tracked down/fixed the two major bugs that needed ASAP attention... and now I can't check them in. At some point I tried to revert a trivial change on my working directory (and of course GIT decides to include a command called revert that doesn't do a revert as known by any other SCC system, so I tried another command that seemed like the right one, having remembered that revert was pointlessly redefined, but not what it was redefined to be) so that I could pull from my home machine to the work laptop...

And now I can't convince the working directory on the laptop to push it's changes to the dev.laptop.org server. It spins for a second and tells me that all the changes are up to date, though they are not. I gather it is either using the home machine or it's just broken. It's also complaining that "HEAD" is an ambiguous reference every time I commit (whatever that command was I tried to use to revert).

I'm very strongly tempted to switch to using bzr for the OLPCGames project... I know, I know. I won't because then we'd have no repository backup available and it wouldn't match the rest of the project and would have no Trac integration... I know, I know. I just hate the thought that I'm once again going to have to blow away the whole freaking checkout and manually apply a diff to try to get things back in sync.

I'm just getting so frustrated with the wasted time working with GIT (this started during the Productive sprint, where we lost many hours to GIT problems), it seems I can spend 10-20% of my working time dealing with GIT inanity rather than solving problems (that I really shouldn't be working on during working hours anyway). I'm sure GIT must be ever so productive for someone, somewhere, but I am definitely not that person... and now I've wasted another 5 minutes ranting about it...

Comments

Mike McLean on 02/05/2008 4:47 p.m. #

I think the command you wanted was git-reset. Perhaps this is the "other command" you're referring to. Running git-status or gitk might help you sort out what's going on in your cloned repo. 
I agree that git syntax is messy, but I seem to be growing accustomed to it.
Jay P on 02/05/2008 5:15 p.m. #

I'm hoping for the day when someone releases a more full featured GIT tutorial, something that takes you through a very thorough set of typical occurrences. 
 
I really like git, but I'm often away from programming for 2-3 weeks at a time, and I find I always have to go back and remind myself how some things work. Always worth it in the end. The power of instant and cheap branches alone is enough for me.
Ian Bicking on 02/05/2008 5:22 p.m. #

While I've found hg pleasantly simple (and svn-like), I've become a bit interested in bzr and Launchpad, as Launchpad seems to have some interesting bzr hosting options, hosting not just the main line of development but also keeping track of any other repositories people want to publish. So if you really want to get distributed with your DVCS, Launchpad gives those people who aren't committing to the main repository a way to persistently record and publish their repositories. 
 
Of course it still doesn't fit with the rest of the project, but then for Launchpad this stuff is their core competency, but it's really not a top priority for OLPC (and it shouldn't be).
Mirko on 02/05/2008 5:24 p.m. #

I have not used Git much myself yet, but I have heard good things about the Peepcode Git Screencast: 
 
http://peepcode.com/products/git
Mike Fletcher on 02/05/2008 8:26 p.m. #

I wound up doing a log of the git repository, taking a diff back to the first commit this morning and then applying that diff to the checkout on the workstation (which wasn't messed up). That let me push up to dev.laptop.org. 
 
Thanks for the pointers for tutorials. Launchpad is interesting to me too. Wish I had time to play with it more. 
 
git-reset might be the right command... but darned if I can tell from reading the man page whether it really is... it seems like I want a --hard flag with HEAD? Why wouldn't they include "works like svn/cvs revert" in their examples? 
 
Okay, enough ranting from me on this topic...
Alan on 02/06/2008 3:15 a.m. #

Yes, that sounds right.
Alex Riesen on 02/06/2008 6:04 a.m. #

"git reset --hard " will not only reset your active branch to the . It will also blow all changes you made in your working directory but have not committed yet (except for the new files). 
 
Before you do something like that (and if you, like now, are not sure of what you're doing) save the current state as good as possible. Something like that: 
 
git commit -a -m"Saved state" 
git branch -f last-saved-state 
 
Than do your "git reset --hard". 
 
And there will be a lot of people who don't share your opinion regarding "git revert". Try suggesting on git@vger.kernel.org (not just because they're set in their ways, but because they'll have reasons for that. Which will be said). 
 
Regarding your "git push" command not working as you expect: have you ever looked at "git gui"? 
Maybe the configuration needed for that command will be more obvious if you look at it through that tool?
rmxz on 02/26/2008 11 p.m. #

git-gui ("apt-get git-gui" on debian; I wouldn't know for other distros)is another convenient crutch if you can't remember the git commands or read the "git help" output or read the man pages. 
 
It has a point&click menu where "branch...reset" would do what you wanted. 
 
Personally I find the git help and manpages easier; but some people I know like the GUI.
Mike Fletcher on 02/27/2008 8:43 a.m. #

While a GUI might be fine for some people, I'm not one of them. I often work on remote servers. I also daily, hourly, minutely even, use cvs, svn and bzr without any need for a GUI. 
 
I *did* read the GIT man-pages for the various sub-commands I was looking at (note one instance mentioned in the comments above)... and it was largely impenetrable, describing everything in its own internal jargon, instead of describing the *effect* that the user wants to accomplish. 
 
I can get by with the man pages, (or more frequently just command-line --help flags), for the other SCC systems, simple, obvious descriptions of how to accomplish a task, and a relatively common/similar set of commands for all of them. The commands mean the same basic thing in each system, there might be a twist here or there, but if something says "revert" it means "revert" in the same basic way as everything else. If something fails, the other systems normally given enough information that I can fix the problem without any further research. With GIT the error messages are so opaque that you can spend an hour trying to figure out how to recover from a simple botched merge. 
 
The other SCC systems aren't perfect, but they don't get in the way of working. GIT seems to go out of its way to require you to become a devotee of the package before you are allowed to get your day's work finished.
Jakub Narebski on 05/06/2008 5:48 p.m. #

Try "Git User's Manual", http://www.kernel.org/pub/software/scm/git/docs/user-manual.html 
 
As to different terminology than used by other SCMs: there is no _one_ single consistent terminology. git-revert is roughly equivalent of hg-backout, i.e. it is about creating commit reverting changes, not bringing file to version in index or HEAD, i.e. "git checkout -- ''file''", or "git reset -- ''file''" (the latter with new enough git).
Jim on 07/25/2010 1:02 p.m. #

> and would have no Trac integration

The trac-bzr plugin[1] seems to provide good integration between bzr and trac.

As a long time bzr user I tend to use bzr + trac for private hosting on my server and launchpad for public projects. Launchpad has some neat features like peer review and a solid bug tracker thats tightly integrated with branches and reviews. bzr command line also plays well with launchpad.

[1] https://launchpad.net/trac-bzr