Re: State of the repository conversion

[Eli Zaretskii <eliz@gnu.org>]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Wed, 19 Mar 2014 13:51:24 -0400 (EDT)
> 
> >From Eli Zaretskii:
> 
>      . I would suggest describing the setup of git-merge-changelog,
>        because as long as we keep ChangeLog files in the repository,
>        people might bump into conflicts in the logs, and it would be nice
>        to avoid that.
> 
> If this is really important to have on the Emacs wiki, someone else will have
> to do it. Search engines don't turn up documentation on the tool and I
> don't have direct experience with it.

The documentation for git-merge-changelog is available as a large
commentary at the beginning of the source.  Also, someone created a
man page out of that commentary and posted it to the gnulib mailing
list a week or two ago.

>      . I think we should discuss some more how to work with the
>        development trunk and the release branch in parallel, and reflect
>        the results of the discussion in the Wiki.
> 
>        The issue here is that the release branch and the trunk diverge
>        very quickly after the branch point, and the result is that after
>        you checkout the other branch, you generally need a very long
>        build, many times a full bootstrap.  While on a modern system, a
>        full bootstrap should take a few minutes, it is still annoyingly
>        long, and makes higher the risk of losing the race against other
>        committers.  In addition, you only have a single executable at any
>        given time, so comparison of behavior between the two branches is
>        difficult.
> 
>        So perhaps we should find a way of having two separate branches,
>        such that switching between them does not require a build if
>        nothing changed.
> 
> This is not a documentation request, it's a research agenda.

It was a request to discuss and decide upon the recommended workflow.
Documenting the decision is the easy part.  We did something very
similar when we switched from CVS to bzr, and the results are on the
wiki.  The current Git wiki page simply repeats what the bzr workflow
said, which is probably sub-optimal, since Git is not bzr.