[Groff] Git branching workflow (was: License for files with »ideal« parts)

[Bertrand Garrigues]

Hello Steffen,

On Tue, Sep 16 2014 at 11:19:41 AM, Steffen Nurpmeso <address@hidden> wrote:
>   [1] <https://www.gitbook.io/download/pdf/book/gitbookio/progit?lang=en>
>
> Why does groff not take advantage of git(1) and introduce a second
> regular work branch?  I think that has been mentioned several
> times on this list already?  Like this work will progress in there
> (say [next]), and faulty commits can be adjusted / illegal content
> removed (and simply via rebasing [next], or alternatively by not
> cherry-picking individual changesets onto [master], whatever route
> there will be taken) before they ever reach the immutable
> [master].  Once the maintainer merges / cherry-picks [next] data
> into [master], the [next] can be reset, and a new cycle starts.
>
> Another advantage of doing so, instead of having, e.g., branches
> for each contributor or for individual topics (like autoconf), is
> that the groff community works with a single HEAD that contains
> all the current changes, and which thus gets compiled and used /
> tested by quite a lot of people on multiple machines, while still
> being able to be select what ends in the immutable [master].

Just some thoughts on the subject,

It's a good idea to have a 'next' branch that contains all the novelties
to be thoroughly tested before there are merged into master. However
people would still need 'topic branches' for a specific development (as
described in the Pro Git book; 'man gitworkflows' also gives good hints
on the possible workflows) because they don't want to be disturbed by
(or disturb) other on-going works.  Also, 'topic branches' should be
created from 'next', and therefore frequent rebases or history changes
on the 'next' branch should be avoided (done only when the maintainer
merges the 'next' branch into 'master before resetting it, or when there
is no pending topic branch).

Alternatively, given that the average number of commits on the groff
project is not that big, we could just systematically use 'topic
branches' with a review of the work before merging into master.

Regards,

--
Bertrand Garrigues