Am Montag, den 08.12.2008, 18:17 +0100 schrieb David Paleino: > On Mon, 08 Dec 2008 16:54:17 +0100, Manuel Prinz wrote: > > Sorry, but that you do not see the advantages does not mean they > don't > > exist. > > 1) "[I] am not really comfortable learning git" > 2) "it *must* have something good", > 3) "the only thing I saw [..] is *speed*" > > Am I saying git is bad? ;) I read the last two points as sarcasm. Sorry! > I was referring to my own experience, and in some other mail I already stated > that I probably haven't used git at its full power (as also Andreas stated). > > > [1] I do not provide the points I care about because I think they do not > > contribute to the point I am trying to make. If anyone is interested, I > > can of course name them. > > I am, and I believe that naming the points pro-git is useful for the thread. The advantages of Git are IMHO: * Speed. ;) * Excellent branch/merge support. That's fast and cheap and allows one to have several independant branches to work on. This is especially handy if you need to touch upstream's code, as it makes changes more visible than a huge quilt-patch. * Support for cherry-picking. Importing changes from other developers easily can be very handy at times. (I sometimes even cherry-pick from my own branches.) * With TopGit: Automatic patch generation from branches. No real need to update a series quilt patches, one can auto-create them. (This also has the nice side effect that it does not clutter the commit diff.) * "All in one" repo: Upstream code + Debian packaging as seperate branch. With pristine-tar, I can recreate the upstream tarball when not available. svn-bp just does not work if you're on the road and don't have the tarball. (Keeping all tarballs for all versions costs disk space as well, which is limited on my EEE.) * Offline commits. This is my personal favorite since I'm quite often lacking an internet connection. Commiting regularly is IMHO important, especially if a revert is needed. (I used SVK for years but was never happy with it; merge conflicts were just a pain back then with SVN. Heared the new SVN version fixes it somewhat. But SVK was an improvement in that point.) * Git is stupid. It means that it does not try to guess anything if can't decide what to do. The user has to be explicit in what he wants to do; you (almost) never get any "smart" behavior from Git. There is no unexpected behavior since you request Git to do what it should do. (I do not like unexpected behavior due to "smart" software. That's probably more a personal point.) * Import and export of patches from and to email. This is just great: Take a diff and export it to an email, add a comment and send it. Other Git users can simply apply it to their repo from their mail client. (Or save the mail to a file and apply that with the Git tools.) Once used to it, it's very handy and makes exchanging patches really easy. As an example: In maintaining Open MPI, we have currently several issues to solve. With different branches, I can address all of them seperately which I do find the time. Hacking at all in the trunk clutters history a lot and causes confusion. We chose SVN in the team but I use a private Git repo to do the actual work and commit diffs later. This is mostly because of the offline arguments and the fact that I have everything available in my Git repo: packaging work and upstream code. When done, I can create patches for quilt or to send to upstream directly. Dealing with new upstream versions is as well more easy. But I can't quanitfy that, it just feels this way. > > [..] VCS are tools to do a job, and if one > > can do that job more effectively or efficiently, one should not have to > > argue again and again why (s)he uses that tool. > > I'm not arguing, and I'm in favour of changing {D,}VCS, but only if that brings > notable profit to our current workflow. I don't think I'm wanting too > much! ;) OK. I agree that you don't. ;) > > [..] "I like $MYVCS, and all others suck" discussions lead to nowhere. > > I don't believe I made such a statement, please don't generalize, thank you. Sorry, I read a tone in your mail that just wasn't there. I apologize! So we had a misunderstanding, I'm sorry for that! (Maybe it was just a little too much d-{d,p,v} lately.) I surely did not want to kill the fun. Hope we're fine and can go on... It was not my intention to offend you. Best regards Manuel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil