also sprach Stefano Zacchiroli <z...@debian.org> [2009.05.24.1557 +0200]: > I think the approach hinted by Mehdi is quite interesting and that > it deserves a bit more of investigation.
Fair enough, I probably don't understand it yet. Let me reply to your mail first, maybe you can point out where I am misled. I am also asking Mehdi at the bottom to provide some more details over the process of making a change to a patch. > In particular, what do you think you will loose practically using > that instead of full-fledged TopGit? 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: 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. 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. 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). > 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. Mehdi, I may not be understanding the approach you take when a patch needs updating. Could you share that with more details with us? 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? With TopGit, you'd have four TopGit branches and the patch series would be created by exporting the patches for each feature branch. When you need to make a change to B, you checkout B, commit until you're done, and then let TopGit update branches C and D to ensure that they apply, before you export the new patch series. 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. 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? -- .''`. 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 "violence is the last refuge of the incompetent" -- isaac asimov
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