Re: git branch strategy after 1.11
On Sunday 2009-03-22 12:23, Ralf Wildenhues wrote: >Hello everyone, > >just to let you know, after 1.11 I intend to change the branch setup a >bit. When branch-1-11 is created, I will also create a branch maint, >which will then receive bug fixes appropriate for both 1.11.x and 1.11a. >The maint branch will then be merged regularly (most likely after every >commit or set of commits) into both branch-1-11 and master. Perhaps use a dot? e.g. "branch-1.11". And: once branch-1.11 development finally ceases, it can be deleted. This works because the commits remain reachable via the release tags. If necessary, the branch pointer can simply be recreated. >An alternative naming strategy would be maint-1-11. That way it would >be simpler to add bugfixes to branch-1-10 even after the maintenance >branch has moved to the branch-1-12 branch point. OTOH, if we want to >fix things in old branches, we can always open up a new oldmaint or >maint-X-Y branch then.
Re: git branch strategy after 1.11
Hi Jan, * Jan Engelhardt wrote on Tue, Mar 24, 2009 at 08:56:08AM CET: > On Sunday 2009-03-22 12:23, Ralf Wildenhues wrote: > > > >just to let you know, after 1.11 I intend to change the branch setup a > >bit. When branch-1-11 is created, I will also create a branch maint, > >which will then receive bug fixes appropriate for both 1.11.x and 1.11a. > >The maint branch will then be merged regularly (most likely after every > >commit or set of commits) into both branch-1-11 and master. > > Perhaps use a dot? e.g. "branch-1.11". That would depart from the current naming scheme, but yes, I guess that is in the line with changing the tag naming scheme to v1.10.2 etc. > And: once branch-1.11 development finally ceases, it can be deleted. > This works because the commits remain reachable via the release tags. > If necessary, the branch pointer can simply be recreated. What would be the advantage of deleting a release branch? What I had in mind was keeping the release branches as we do now, and pushing the occasional bugfix there that distributors are likely to pick up, rather than each roll their own, slightly incompatible one. OTOH, with temporary feature branches like je-silent or ad-parallel-tests it seems useful to delete them sometime after they have been completely merged into master, and we don't expect further bug fixes in the area. Thanks, Ralf
Re: git branch strategy after 1.11
Hi Ralf, On Tuesday 2009-03-24 22:48, Ralf Wildenhues wrote: > >> And: once branch-1.11 development finally ceases, it can be deleted. >> This works because the commits remain reachable via the release tags. >> If necessary, the branch pointer can simply be recreated. > >What would be the advantage of deleting a release branch? Maybe, first, to clarify, doing this deletion is only meaningful when the branch pointer would coincide with a tag. Otherwise you would lose commits if the bp deviated from what is reachable from the tag, of course. Hm, less refs to download for the user. Not that those 40 bytes matter ;-) Seriously, I really thought "whoops" when I was swamped by the lot of branches in http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=heads when I downloaded it once to cherrypick some commits. >What I had in mind was keeping the release branches as we do now, >and pushing the occasional bugfix there that distributors are likely >to pick up, rather than each roll their own, slightly incompatible one. Nothing to say against that in itself. >OTOH, with temporary feature branches like je-silent or ad-parallel-tests >it seems useful to delete them sometime after they have been completely >merged into master, and we don't expect further bug fixes in the area. And if there does happen to be a fix to that specific branch (hypothethically; realisitically we'd just slap it onto master), you just recreate the branch at the last commit, apply the patch, push out the branch. Since it is a fast-forward for users who still have the branch pointer with its old value, there are no unexpected interruptions. Jan
Re: git branch strategy after 1.11
* Jan Engelhardt wrote on Tue, Mar 24, 2009 at 11:01:02PM CET: > On Tuesday 2009-03-24 22:48, Ralf Wildenhues wrote: > > > >> And: once branch-1.11 development finally ceases, it can be deleted. > >> This works because the commits remain reachable via the release tags. > >> If necessary, the branch pointer can simply be recreated. > > > >What would be the advantage of deleting a release branch? > > Maybe, first, to clarify, doing this deletion is only meaningful > when the branch pointer would coincide with a tag. Otherwise you > would lose commits if the bp deviated from what is reachable from > the tag, of course. The branch pointer would almost never coincide with a tag. The first thing I do after a release is to bump NEWS and configure.ac. This may be a relict from not computing the version number from 'git describe', but I currently don't see the need to go this way. > Hm, less refs to download for the user. Not that those 40 bytes matter ;-) > Seriously, I really thought "whoops" when I was swamped by the lot of > branches [...] The number of release branches will not grow anywhere as quickly here. Thanks, Ralf
ylwrap fails with name-prefixed .l file
Hi, when a scanner.l file contains %option prefix="foo_" flex will output to lex.foo_.c instead of lex.yy.c, causing ylwrap to fail (automake runs:) /bin/sh ../ylwrap scanner.l lex.yy.c scanner.c -- flex How would one best proceed here? Especially when there are multiple lexers/parsers possible, so just removing %option prefix is likely to end in a link-time "double definition" error. Jan
ylwrap and flex --header-file
Hi,
when one uses --header-file in conjunction with ylwrap, the header file
is produced in the temporary directory ylwrap runs in instead of
${srcdir}. I think this should be addresses somehow - I'm open
to suggestions or ideas on how this could be tackled. One way would
probably just to add ../ in the right place.
# -*- Makefile -*-
AM_LFLAGS = --header-file=$(<:.l=.h)
foo_SOURCES = scanner.l main.c
scanner.h: scanner.l
/* main.c */
#include "scanner.h"
main_program_here
