On Mon, 3 Oct 2011 19:16:09 +0200 Jiří Techet <tec...@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. ;) I agree. Cheers, Frank -- http://frank.uvena.de/en/
pgpBopVCwVTO5.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel