Actual IM conversation:
[me]: ever use git?
[them]: Why would I do such a thing?
[me]: peer pressure, because all of your co-devs
told you it was the cool thing to do
I thought that developing the software that drives FATE would serve as a good opportunity to learn the Git source control software. Foolish.
Git terrifies me. Thing is, I make mistakes. Lots of mistakes. I need a source control management system (SCM) that is sympathetic to my incompetence. As it stands, when I make a mistake, I have to dig through 140 git-* commands on my system to try to guess which one just might offer a shimmering hope of redemption. If I choose poorly, I will only exacerbate the situation as well as pollute the official history log. Such was the case when I tried to revert one particular commit. I can’t remember how that worked out exactly. I guess I got the correct code back eventually, but the log file tells a sordid tale.
More recently, I edited a file but decided I didn’t want the changes; I wanted the previous committed version back. Perhaps use git-revert, like most other SCMs? Goodness, no. Maybe git-reset? Guess again. Turns out git-checkout is what I was looking for (thanks, Mans). Now, I have made the mistake of using git-commit in such a way that actually committed more files than I thought it would (serves me right for following examples and not reading the pedantic documentation first). Now I find myself wanting to undo the commit for one particular file but not actually lose the changes.
Here’s a solution that can’t fail: ‘rm -rf .git/’, followed by a re-reading of how to initialize a local Subversion repository. And whose idea was it to tag revisions with random 160-bit hex codes like 488dfe6a946bbbbb4e095a5d758ad9808f7336b1? (Yeah, I know, they’re SHA-1 codes or some such. I don’t care; it’s still not human-friendly). I hope FFmpeg never gets around to making the switch.
I have to agree with your sentiments about GIT, it’s still simply not very user-friendly. Although I’m certain that it is possibly the most efficient dVCS around, I personally have chosen to utilize either SVN (for those cases where I don’t “need” distributed version management) and Mercurial.
At least Mercurial is pretty user-friendly and certainly simpler to use than GIT. The only misgiving I’ve had with it, is the in-repository branching, which is somewhat confusing, but it’s an easy enough issue to remedy: just don’t use in-repository branching, clone separate repos for different branches! :)
In terms of efficiency, I’m not very sure if Mercurial scales well enough for very large projects, though we do use it for Audacious (a XMMS-descendant music player) http://audacious-media-player.org/ , and there it performs ok. YMMV.
I still consider git with git-svn the best variant for the central repository, though I would really love it if every ffmpeg developer could publish their changes on a semi-offical, shared git server.
Just be glad you haven’t had to endure the pain that is Rational ClearCase
While I am using GIT for my own repositories (and it’s just because it’s simpler to set them up remotely), I agree that is not very ready yet.
Not only it is far from user-friendly in general (as you said already), it also does NOT follow the same convention as almost any other SCM out there (revert is a good example).
Also setting up CIA and commit mails is a major PITA. I was able to streamline CIA setup, but I’m still messed up with the commit mails.
I thank Darren for choosing Mercurial for xine!
First, you don’t need to use all those 140 commands. Most of them are meant to be used in scripts only, not for end user. For work you would need no more than around 25 commands.
Second, if you have new enough git, “git reset –hard ” should work. “git revert” is for making revert _commit_.
But the main thing is that git allows you to correct your mistakes. “git commit –amend” allow you to correct topmost (latest) commit. Interactive rebase (and optionally StGit or Guilt Quilt-like patch management interfaces) allow you to reorder and rewrite history of a given branch to your wishes. “git reset –hard ” allows you to just forget some commits. Git is very flexible in this regard. And all this avaliable from git commands, without need to muddle into repository itself.
And “log files”, assuming that you ment reflog here, are (and must be) purely _local_ matter, so noone wexept you would see them. Reflog is here for when you made mistake e.g. when recovering a commit.
P.S. as with all tools, power comes at the expense of complexness.
http://wiki.winehq.org/GitWine
http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png
everything is simple if you have the good documentation =)
yes, I do hate svn and I like git, setting up the commits+cia stuff for lscube took me less than expected, mostly because I dug the scripts
git has about 5 to 10 commands that you use the 99% of the time, the rest is something nice you may or may not use.
once you discover how git-reset, git-checkout, git-push, git pull, git add, git commit works you have covered almost everything.
git branch, git mv, git rebase, git merge, git grep, git status and git diff are useful too but not exactly fundamental
Pingback: Unieject moves to GIT
Mike, have you given Mercurial (hg) a try? I have started reading up on it, it does look quite promising and not such a usability nightmare as git…
Unfortunately, I sort of have a code investment in git at this point. Unless there’s a handy git->hg converter.
I have been exposed to the hg system since the current xine maintainers use it. I have not committed anything under the current management, though.
Yes, hg can convert git repositories, at least this is claimed. I have not tried for myself. I’ll be happy to hear about your experiences :)
http://hgbook.red-bean.com/hgbookch1.html#x5-240001.7
http://www.selenic.com/mercurial/wiki/index.cgi/GitConversion
Maybe I’ll maintain my source in both just for the redundancy.
Git has a learning curve, but all tools do. When I first started with SVN I spent several days on a play repository creating, deleting and merging branches until I understood how to do things properly.
Git’s learning curve is probably longer than most, because it is such a powerful system. But there’s a basic core set of commands for almost all day-to-day work. And once you’ve learned how to recover from a mistaken rm or a foolish commit, you won’t forget what to do.
I use StGit a lot, it’s a patch management system which works on top of a git repository. That makes committing and fixing commits much easier. It forces me to separate changes into their logical components. For example – first patch will be whitespace fixes and other formatting. Next few patches will be adding new functions. Next few patches will be changing existing code to use the new functions. Last patches will be deleting obsolete functions. If I make a mistake in a patch I can go back to it, revise and move forward again to the latest patch. When I’m happy with all of them I can “stg commit” and that turns the stgit patches into regular git commits, which I can send upstream.