Hello, martin f krafft a écrit : > From what I understand, Mehdi's (and Guido's) approach require > a branch with one-patch-per-commit, which they rebase. This approach > has two problems for me:
I do use this approach, too. Actually, I took the idea from Guido's packages and taught it to Mehdi and Stefano (and will probably to the remaining of the OCaml Team) ;-) > 1. due to the rebasing, it's not possible to work with other people, > unless everyone maintains their own patch queue. > > 2. each patch on the patch queue branch is presumably the result of > a squash-commit or the like. The feature has likely been > developed on a branch of its own, squashed into a single commit, > and then removed. 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... TopGit seems great if you actually do upstream development without being formally upstream (i.e. don't have direct commit access), in collaboration with other people. IMHO, this doesn't match the task of packaging for a distribution. Don't be mistaken: I don't say that packagers must not work on upstream features; I just say they shouldn't do it as part of their Debian packaging. > 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" ;-) > It gets worse if you do publish the feature branch, because then > you need to keep it up to date with other branches by merging > before you can work on it and squash-commit. > > TopGit automates all of (2) and since it never rebases, it can be > used in a team (1). The feature branch is not meant to be exported, nor touched frequently, only on new upstream release and Debian releases that fix bugs in upstream. For my own packages, this doesn't happen often (but of course, I am aware that this might not be the case for everyone). >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. >> Also, your patch history is trivially versioned as the content of >> debian/patches/ in master. > > You will be able to work with diffs of diffs. My head spins when > I have to do that. Sure. But as I said, that shouldn't happen too often and the complexity of TopGit doesn't seem worth getting familiar with. > 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 # hack, git add the changes git commit --amend -c HEAD # use -C if there is no need to change the comment git rebase --continue # git will guide you if there are conflicts > I think TopGit gives you the benefit of working with Git for > everything, and using quilt only to apply the patches. Git offers > cherry-picking, can obsolete patches if the resulting content of two > of them i identical, gives you access to a log, diffs, and much > more. It allows you to develop a feature, rather than versioning > a patch. Indeed, recontructing the history of a patched file might be more difficult with our approach. On the other hand, in my experience, that history is generally not too long (one commit + updates at each upstream release), and I think seeing the history of the patch itself is largely sufficient for our purpose. I think our role as Debian (or whatever) packagers is versioning patches, rather than developing features :-) > 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. Cheers, -- Stéphane _______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
