Hi Martin, On Mon, May 25, 2009 at 10:52:42AM +0200, martin f krafft wrote: > 1. due to the rebasing, it's not possible to work with other people, > unless everyone maintains their own patch queue. Not true. You just have to agree beforehand what branches do keep the patch queues (therefore the patch-queue namespace) and you have to fetch them with a refspec that starts with a plus sign (see git-fetch (1) and look for <refspec>).
> 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. In practice I found this to be quiet seldom the case and you can always keep the feature branch around (I usually don't but rather try to get the code merged upstream). I don't mean to say that TopGit isn't a nicer way to do this. I just never got around to wrap my head around it. Cheers, -- Guido _______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
