Am Mittwoch, den 10.12.2008, 00:12 +0100 schrieb David Paleino: > 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. I'm not sure if this is a sane thing to do from upstream, but that's a different matter... > So, if I chose git, I would need to split out 17 (or $n) branches everytime > upstream makes a new release? Yes, you probably would. As said, it may sound scary but it really is not. It's one of the things TopGit tries to solve (for you). It should not be much of a deal. In any case, your package seems to be very interesting since it does not reflect the typical situation when dealing with upstream sources. I hope to find some time soon to have a closer look at it. It might be a good example to learn to understand how this can fit in the currently proposed workflows; maybe it's even a base for a new one. Thanks for pointing it to me! > 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!) ;) As said, it has the problem that the patches are flattened and maybe inter-dependant, without any chance to nice this from mere looking at it. As nice as p-t.d.n is, it is no substitution for a VCS. Or are the patches really distinct? If yes, how is this achieved? > 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) And I'll probably have a look at john, it seems interesting! Based on a conversation with Andreas I'll try to write a proposal for a workflow on packaging with Git for the Debian Science scope. I guess this could easily be adopted by interested Debian Med people. If anyone is interested in working on this, please feel free to join the effort. Since Git lets one do pretty much everything you want, this will of course just be a proposal; work-flows are pretty much person-dependant. But I'm hopeful that there is one that fits the most common cases. > Thank you for contributing to the thread, Thanks to you too! Best regards Manuel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil