[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Git transition checklist
From: |
Eli Zaretskii |
Subject: |
Re: Git transition checklist |
Date: |
Thu, 09 Jan 2014 21:03:20 +0200 |
> 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.
- Re: Git transition checklist, (continued)
- Re: Git transition checklist, Eric S. Raymond, 2014/01/09
- Re: Git transition checklist, Glenn Morris, 2014/01/08
- Re: Git transition checklist, Stephen J. Turnbull, 2014/01/08
- Re: Git transition checklist, Eli Zaretskii, 2014/01/09
- Re: Git transition checklist, Stephen J. Turnbull, 2014/01/09
- Re: Git transition checklist, Andreas Schwab, 2014/01/09
- Re: Git transition checklist, Stephen J. Turnbull, 2014/01/09
- Re: Git transition checklist, David Kastrup, 2014/01/09
- Re: Git transition checklist, Eli Zaretskii, 2014/01/09
- Re: Git transition checklist, Stephen J. Turnbull, 2014/01/09
- Re: Git transition checklist,
Eli Zaretskii <=
- Re: Git transition checklist, Óscar Fuentes, 2014/01/09
- Re: Git transition checklist, Eli Zaretskii, 2014/01/09
- Re: Git transition checklist, Óscar Fuentes, 2014/01/09
- Re: Git transition checklist, Glenn Morris, 2014/01/09
- Re: Git transition checklist, Eli Zaretskii, 2014/01/09
- Re: Git transition checklist, Óscar Fuentes, 2014/01/09
- Re: Git transition checklist, Eli Zaretskii, 2014/01/10
- Re: Git transition checklist, Eli Zaretskii, 2014/01/11
- Re: Git transition checklist, Glenn Morris, 2014/01/11
- Re: Git transition checklist, David Kastrup, 2014/01/11