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

[Steffen Nurpmeso]

Hello Bertrand,

Bertrand Garrigues <address@hidden> wrote:
 |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

 |> 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].

First i'm sorry that i didn't really test your work on the
migration to autoxy.  I personally declined completely to use
these back around 2001 and rather spend about half a year writing
a perl(1) based configuration, build and installation facility.

And today i'm really in favour of POSIX and what it ships: sh(1),
awk(1), etc.  It must be said that most of the entries that need
to be configured for groff were already present in Issue 1 of
POSIX (!!), and i don't think that groff would at all compile on
systems that are this old, even if there would be modern compilers
available.

Granted that it may be easier to deal with the one or other
system-specific or C-library specific bug.
But imho: what this codebase really needs is a complete overhaul,
move of bug-specific hacks to shared code -- just grep NEED_DECL
in src/ and see how often such missing _declarations_ are checked
in _sources_ --, not a different configuration system.
For S-roff all this has to and _will_ vanish.
I don't see a point in complicating user's life with the remains.
My point of view.

 |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

(U-hu, i've read it and worked along with it once -- it helped! --
and then copied over what i often forget, and that really only is
  :read!cd ~/arena/docs.coding/ && ls -l prog*
  -rw-r--r--@ 1 steffen  staff  69410 22 Sep  2011 progit-06.markdown
  -rw-r--r--@ 1 steffen  staff  63354 22 Sep  2011 progit-09.markdown
I just looked on that shared hoster yesterday..  I'm not sure, but
i think back then there were no translations at all..  well.)

 |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.

Sure!  If e.g. VM guy Bob and VM girl Alice develop a new VM
subsystem that is highly speculative, or instable or not yet
worked out then git(1) makes it easy and cheap to do so in some
topic branch, and interested parties can easily add this branch to
their portfolio of local branches and (hopefully) simply merge it
"on top" (of [next] or whatever they use for building) and help
testing this / these particular change(s).

E.g., the VM changes of Bob and Alice plus the tmpfs support from
Mick plus the runit system service supervision integration that
Herbert is working on.. on top of "regular" [next].
This can be easily done if Bob, Alice, Mick and Herbert ensure
that their branches are in a state that makes them mergeable (with
--no-ff --commit) onto, e.g., [next].
Of course *you* have to perform the merge in this case, locally.
(gits "rerere" command can even help in doing so, but i've never
used it until today.)

Diversifying the active set of branches naturally decreases the
number of people which actively use changes that rot in some topic
branch, which is in effect all that i wanted to say.  E.g., if
you're done with the automake integration topic branch, then i as
a maintainer would merge it onto [next], first with a merge
commit, so that the branch remains intact.  Shall then defects
show up, because of the broader audience and their testing, you
could fix the bug in the topic branch, which then can be
re-merged for broad testing (after being rebased by you so that
a --ff-only merge would be possible?).  Finally the branch could
either be merged into [next] so that it completely works out
(loosing all information that it actually was a topic branch), or
simply be merged in via an explicit merge commit, just as before,
but now rather fixed.

So, finally, it turns out that i think that it is essential that
there is a main development branch which carries as many changes
as possible.

And another good news -- just call "$ git gc --aggressive" when
you're done, and the repository will be cleaned from all that
development garbage.

--steffen