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