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.
 -- Guido

vcs-pkg-discuss mailing list

Reply via email to