Re: Git transition checklist

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden,
>     address@hidden
> Date: Fri, 10 Jan 2014 03:46:45 +0900
> 
>  > jobs to be covered are, I think, (a) updating each branch from
>  > upstream and (b) merging and/or cherry-picking commits between the two
>  > branches each one of which is in a separate repository.  TIA.
> 
> No, both branches must be in the same repository to perform those
> operations.

I somehow understood that if one does "git remote add" to track the
other repository, one can then fetch from there and merge or
cherry-pick from the fetched commits.  Is that wrong?

> What this implies for Emacs release workflows I can't say because I
> don't know how the Emacs release workflow works, specifically who
> commits the merges and cherry-picks.

Merges from the release branch to the trunk can be currently done by
anyone with write access.  The only requirement is to follow the
protocol encoded in admin/bzrmerge.el, which in a nutshell merges all
the revisions from the last merge point "till now", and then
selectively reverts the changes we don't want on the trunk (e.g.,
because a different fix for the same problem was committed to the
trunk).

> The issue about multiple repositories is about whether a single
> developer's feature branches should share an object database (at least
> that's what I've been talking about, and I believe Andreas too).  The
> conclusion is that they shouldn't, but this will result in a certain
> number of objects duplicated in several local repos.  However,
> reducing that duplication by --share'ing is not worth the risk of gc
> in the origin repo corrupting the feature branches (because the origin
> repo doesn't know about those branches).

Feature branches worry me much less than the need to work with at
least two (in the future maybe more) public and long-living branches:
the development trunk and the release branch.  As previously
explained, frequent merging between them is a matter of routine, and
since they diverge very quickly after the branching, having them
colocated in the same directory will be a nuisance, because the build
after switching to another branch will be annoyingly long, generally a
full configure+bootstrap will be required.