On Tue, 09 Dec 2008 14:48:12 +0100, Manuel Prinz wrote:
> Am Montag, den 08.12.2008, 18:17 +0100 schrieb David Paleino:
> > [..]
> >
> > Am I saying git is bad? ;)
>
> I read the last two points as sarcasm. Sorry!
Np!
> 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.
So, consider a package I'm team-maintaining in Debian, john. I'm currently
applying several patches, something like 17 or so. Should I keep 17 separate
branches for this? And how to handle patches touching the same files but in
different points? (i.e. what the "series", "00list" and kinda files do,
establishing patch applying order)
> * 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.)
What do you mean by "importing changes from other developers"?
I know that this might be related to the concept of DVCS, but isn't this prone
to errors on merge/push?
> * 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.)
Read my consideration at point 1 :)
However, I must admit I don't know what TopGit is, /me looks info on it.
> * "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.)
I've had problems in the past with pristine-tar, but that was probably due to
my lack of "experience" with git. (and no, don't ask me what, I don't really
remember which problems I had :( )
About "not having the tarball", that's what "get-orig-source" targets are for.
Also, if you keep the upstream code in the same repository, how can you
"checkout" different versions? Using different tags? I admit that, if
everything is done via tags and diffs between revisions, you could save lot of
space. But I can't really see why one should work on different versions, at
least more than two -- so the "disk space cost" argument isn't really a point,
IMHO)
> * 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.)
This is a big plus for git -- I hate having to connect to commit my changes.
But, once again, how are merges handled? And if two developers change the same
file in more-or-less the same point? Is git smart enough to handle this?
(again, not against git, just "against" the
commit-in-multiple-repos-and-then-merge mechanism which DVCSes seem to adopt)
> * 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.)
Err... I can't get it :)
I once read that "git is like the factory giving you the pieces and the
instructions sheet, and letting you build your own airplane", while "svn is a
full featured airline that is more-or-less good for all pilots".
> * 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.
This is fine, but it seems like we're having this functionality with "svn
diff". Just a matter of attaching/including that output to a mail ;)
> 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.
Fine. And (repeating my previous question) what if two different bugs involve
the same code at, let's say, the same function, and you solve them in two
different incompatible ways? The various branches will work separately, but
once merged, you'd get unexpected behaviour (it's a stupid example, but since I
usually work in trunk with SVN, I also do separate commits -- thus I can see
the code changing, and not always the "base 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.
Yeah, I believe it's just a matter of getting used to it.
> [..]
> > > [..] "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.
No problem, you've not offended me, I thought you misunderstood my mail, so I
quoted the sentences which might have caused this :)
Sure we can go on now :)
Kindly,
David
--
. ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature