On Sun, Apr 17, 2011 at 07:09:15PM +0200, Dominik Vogt wrote:
> Phew, so much text. :-)
Sorry about that -- I did warn it was lengthy.
> On Sun, Apr 17, 2011 at 01:29:27PM +0100, Thomas Adam wrote:
> > Workflow Ideas
> > ==============
>
> I've had very good experiences with this setup:
>
> * There is a central fvwm release repository somewhere, maybe on
> fvwm.org.
Yes; fvwm.org would suffice.
> * The release repo has the branches release and devel plus any
> additional number of topic branches. It may be a good idea to
> prefix such branches with your initial, e.g. dv-menu-rewrite.
I prefer "initial/short-name-of-branch" as this maps directly to a directory
structure on disk, and helps with any naming problems with branches just
because it's done at the filesystem level, but YMMV.
> * The release branch is *never* rewound, rebased or merged with
> any other branch. The *only* way to get anything committed to
> the release branch is to apply patch sets (git-format-patch,
> git-am, git-cherry-pcik etc.). Rationale: In the official
> release branch the commit history must not be changed. Also, it
> can become very difficult to maintain when long term branches
> are merged into the master - this is something you usually want
> to avoid. It is absolutely forbidden to publish changes to the
> release branch with the force option of git-pull or git-push!
Yes -- I hoped I'd made that clear, but didn't want to really get too boged
down with terms like "rebase" too early. :)
> * On the devel branch, patches are collected prior to publishing
> on the release branch. History of the devel branch may be
> changed at any time to correct mistakes. Development must not
> take place solely on the devel branch because it may be lost by
> accidental parallel work of multiple developers. Usually this
> should not be a problem in fvwm development. If need be, any
> developer can make a short lived own devel branch e.g. dv-devel
> or ta-devel. However, such problems should rather be solved by
> communicating than by creating random branches. In the past
> they happened very rarely with CVS.
Yes, this is fine -- and the implication this has for development (whether
it's obvious or not) is that these topic branches are always initially
created from master (or whichever branch we deem as the "release" branch.)
> * The topic branches should usually belong to only one developer.
> The owner of a topic branch is responsible for keeping it in
> sync with the devel or release branch. The final result of a
> topic branch is a well structured patch set that applies to the
> release branch out of the box (with git-am or git-cherry-pick).
One other option (which helps with the above in terms of keeping things up
to do date) is to consider rebasing local topic branches on top of the
development branch, periodically -- but this breaks down if it's a published
branch with different people tracking it (potentially) -- perhaps
communication alone would help here (it does in git.git's use of "next" for
instance, and that's considerably larger than this project. :P)
> > I personally don't mind 1., above, if the number of branches are small, and
> > well-maintained. Because at some point, once a given feature is developed,
> > and tested in isolation on that branch, it will get merged to another
> > branch. Let's call it "next". The branch "next" is always rewound off the
> > HEAD of master at each release, and will form a "here's what I'm planning to
> > merge to master for release" branch. It might look like this:
> >
> > o--o--o--o--o--o--o--o--o--o--o--o--o--o--o (master)
> > \ \
> > \ o--o--o--o--o--o--o (next)
> > o--o--o--o--o-------------------------/ (ta/titleformat merged)
>
> This is a situation to be avoided, if possible. Merge operations
> are dangerous and hard to track. It is worthwhile to stick to the
I'm surprised to hear you say this, given that git's main feature *is*
merge-tracking, and long-lived topic branches could always be rebased first
of all -- if you also use the "--no-ff" option to "git merge" you'll also
have a merge commit recorded.
> CVS practive: In CVS before you can publish your work, you have
> to update your working tree ("cvs up") and fix the merge
> conflicts. Only a working tree that is up to date can be
> published. The same can be done with git, although it's not
> enforced, by using git-cherry-pick or git-am rather than
> git-merge.
Yes, but the real downside to this, which I think's more important is
that you've now just thrown away the history by not merging. Yes, with
git-am and friends you get a record of the commits, but you don't see where
they came from, etc. And it's now not enough to say "look at the
development" branch because this is rewound at various points, using your
example.
It worries me that we go to all the effort of having developers have topic
branches, etc., only to more or less throw the history away by not merging
them in finally, regardless of the state of the branch before the merge
and/or with --no-ff (i.e., whether the topic branch had been rebased or
not.)
Hmm.
Still, other than managing to talk right past one another, it's encouraging
-- something along these lines might just work. :)
-- Thomas Adam
--
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.
