also sprach Stéphane Glondu <st...@glondu.net> [2009.05.25.1438 +0200]: > You sound like you are developing "complex" features in your Debian > packages, features that might be concurrently developped inside a > packaging team. This doesn't sound right for me. I never do such complex > development inside a package. Most of the time, patches are just fixes > to make the upstream package more Debian-friendly, or patches taken from > upstream's VCS. But maybe I don't maintain "real-life" packages...
I radiated the wrong impression. I think, branches are good and useful for the simplest cases. If all you need to do is change a bit of Makefile, then why should it still live on a branch, the place where you turn to if you ever need to make another related change? 0. e.g. http://git.debian.org/?p=collab-maint/topgit.git;a=commitdiff;h=728be702d0a1e2a0edf8e7dd7ce937c881c9a000 1. http://git.debian.org/?p=collab-maint/topgit.git;a=commitdiff;h=71006efac06e50531c1df1a29aec1c7ddb371895 I don't deny that the log/graph of such a branch, when managed with TopGit, gets messy to the point where it's almost useless to the human consumer, but that's a different problem, isn't it? 2. http://git.debian.org/?p=collab-maint/topgit.git;a=shortlog;h=refs/heads/debian/locations I see your argument and I agree that I don't actually "develop" inside the Debian packaging checkout. I use TopGit mainly in upstream-like scenarios and I love it. I'd simply like to find a unified approach for both types of tasks. > > If the patch needs modification later on, you have to > > recreate a branch and work off the single squash-commit. > > While this prevents you from looking at history, the bigger > > problem is that it's repetitive manual work: create branch, > > cherry-pick patch, work, squash-commit delete branch. > > This "manual" work is trivially scriptable. The same way as > TopGit's work could be done "manually" ;-) My point is that TopGit actually does that manual work already. > >From my point of view, the problem with TopGit is that I don't > (need/have to) use it often enough to be familiar with it. On the other > hand, I am much more familiar with plain git and I don't have to think > long when using it, so I am at ease with Guido's approach. Yes, even thought I think the TopGit UI is quite alright, the innards and what it does to the history are way to confusing. TopGit exposes too much of its internals, and this is a problem. > > Let's say you have a patch queue with patches A, B, C, and D (D is > > the top-most, last patch to be applied) them, and you need to make > > a change to B. What exactly do you do? > > # you are on you re-created patch-queue branch > git rebase -i A > # mark B for editing and save I've never used git-rebase --interactive in this context, but it makes great sense. Thanks for the explanation. > I think our role as Debian (or whatever) packagers is versioning > patches, rather than developing features :-) Interesting argument. I'll have to sleep on that. ;) > > We definitely need to make it easier to use though. This applies > > mostly to the complexity introduced through the various merges. > > If that cannot be simplified, maybe we can find a way to use > > namespaces that don't show up in gitk or similar tools? > > Sure. But as I said above, the gain seems too anecdotical most of > the time (in the context of packaging for a distribution) to > bother learning a new tool. I agree, except that I also wonder if there isn't a way in which we could make the genericity of the TopGit approach easier accessible to everyone. Thanks for some good arguments. I'll need to try this approach Mehdi presented, unless any of you feel like providing a short run-down with examples. I don't think I can quite visualise it yet, especially not in a team context. -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "and no one sings me lullabies, and no one makes me close my eyes, and so i throw the windows wide, and call to you across the sky" -- pink floyd, 1971
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss