[Geany-devel] Plan ahead (to fail to plan is to plan to fail)
frank at xxxxx
Mon Oct 3 17:20:19 UTC 2011
On Mon, 3 Oct 2011 19:16:09 +0200
Jiří Techet <techet at gmail.com> wrote:
> >> 2. I agree with non-fast-forward merges of feature branches. These
> >> branches however have to be real feature branches where work
> >> concentrates on implementing a single feature (e.g. GTK 3 support).
> >> For instance I have a branch for_review with random bugfixes and
> >> minor features which shouldn't be treated as a feature branch and
> >> which can even be rebased on top of master (If you have a look at
> >> GTK, you see only a small number of merges - with bugfix-like
> >> commits there's very small danger that someone else bases work on
> >> them.)
> > Yeah, agreed too. What I like in the blog post's workflow is that
> > *every* single feature gets its own incubation branch, not only
> > "big" ones. This cleans up "master" state, and makes reading the
> > history easier.
> Even in the case of single-commit features? I completely agree with
> more-than-one-commit features because otherwise you don't know where
> the feature implementation starts and ends but having it for minor
> one-commit features seems like overkill to me.
Its hard to say. I would say if its really, really, really only just
one commit, there is no need to build up a branch. But if there is a
chance of a second one ... might be useful. and git checkout -b // git
push origin :<branch> is a fast thing
> I'm not against this idea completely, I just don't feel Geany needs
> it. If you branch before release it adds some overhead because many
> commits will go both to the release branch and to master. Anyway, new
> release is far away so there's plenty of time to decide what's best
> for Geany meanwhile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the Devel