On Tue, 09 Dec 2008 23:39:09 +0100, Manuel Prinz wrote: > [ Sorry, this is a long one! Read it only if you're interested. ;) ] I am :) > Am Dienstag, den 09.12.2008, 20:56 +0100 schrieb David Paleino: > > 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) > > It depends on the workflow you choose. Indeed, having 17 branches sounds > scary but it has some advantages. One thing is that they are distinct, > so commits to a branch belong to a bugfix or feature you develop. It > also allows to get rid of it as soon as the changes are integrated > upstream. Well, I'm patching john (a piece of software out there since 15 years, or so) because upstream doesn't want to include the patches... but provides them in his homepage. So, if I chose git, I would need to split out 17 (or $n) branches everytime upstream makes a new release? > Also, if the changes are split into several commits (for a reason), it is > easy to send all of them upstream without fiddling the right commits from the > commit log. (Alternativ: send one large chunk. From my experience not always > welcome by upstream.) Ok, fine with this. > [..] > Think of having a fix for a real nasty bug in your real-nasty-bug-fix branch: > If you keep it distinct, other distros (like Gentoo or Fedora or whatever) > can cherry-pick the changes in that branch and apply it to their > distribution. (Or the other way round: Debian can profit from them.) Of > course this is quite hypothetical at the moment since not everyone uses > Git and there is no infrastructure that supports the exchange, but it > the situation is not too bad. If you have a flattened patch in a quilt > series, grabbing and integrating that into a different distribution may > be hard or even impossible. So maintaining branches might be for the > profit of the whole FS community. We waste too much time fixing the same > stuff in every distribution already. Making exchange easier is IMHO > worth to achieve. That's not a problem, at least not in Debian-scope. We have <http://patch-tracking.debian.net>, and if you're smart enough not to make a big 00-fix_package.patch, but do different patches (like the 17 I was talking about [0]), other developers can easily cherry-pick the changes (even from a SVN interface!) ;) [0] http://svn.debian.org/viewsvn/pkg-john/trunk/debian/patches/ -- and yes, that's a single big commit done right now, since I did those changes... offline. And git would've helped me there, I believe. > > 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? > > No. Git uses the repository content to define it's state. SVN uses a > revision number. Lets assume you apply commits in different orders than > upstream or a developer, everyone has it's repo in the same state, since > the content is identical. This is usually no problem with Git at all; > but it sometimes is with SVN, since r1234 on your repo might not be > equal to r1234 in the repo of a different developer. Ok, another plus. > [..] > One other point I forgot, because it's too much of a habit now: Every > Git repo is a full repository. It can easily be backuped. In fact, if > you have your repo online, you do have a backup since you can just clone > it. Or clone the repository of a fellow developer. They're all alike. > (Ignoring local changes.) This is surely a real nice thing: If you > destroy your repo, just get it back from somewhere. Another plus, to me. I believe I'll start "trying to use" git more seriously, also just as a test (i.e. doing an hello.c, trying changes, diff, patchsets, and all the features you mentioned) Thank you for contributing to the thread, 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