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.
vcs-pkg-discuss mailing list