As far as I can tell (and I might be horribly misinterpreting git- buildpackage workflows), if I need to make changes to the original source, I need to constantly be checking into a temporary patch-queue branch to do my work. As an avid user of git, this doesn't really match with how I like to work.
I like to be able to see a complete log of my changes as persistent git objects, because I am in the unfortunate habit of making mistakes and wanting to rewind. I think the experience of git-buildpackage could be much improved if that was allowed. Here's how I propose letting developers commit as-they-please, and then working around their changes: 1. Add a new subcommand to gbp-pq: generate (or perhaps a whole new gbp subcommand), which takes the upstream-branch, the debian-branch, and determines the commits that debian-branch has but upstream lacks. It then selects those commands which change files outside of debian/, and formats patches for those changes (as it does now, in git-pq). It adds those patches to Debian/patches, as it would normally. The result would be that I can make changes and refinements to my package without needing to track which branch I am working in. It is possible that the same could be accomplished without even the additional subcommand, simply by changing the basis of the comparison. If when git-pq exports, it compares commits relative to upstream-branch instead of debian-branch, you'd get the same benefit. I would be willing to implement this if need be, but I figured a discussion on how and whether would be good to have beforehand. Thanks, Calum M
signature.asc
Description: This is a digitally signed message part
_______________________________________________ git-buildpackage mailing list [email protected] http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
