[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package "ownership" per team, and the use of `mr' to handle this.



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


Reply to: