From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Workflow to accumulate individual changes?
Date: Thu, 31 Dec 2009 00:54:39 +0200 [thread overview]
Message-ID: <87637of4y8.fsf@kobe.laptop> (raw)
In-Reply-To: <f7ccd24b0912301334u6df4cf24k7625713ba8e4252@mail.gmail.com> (Juanma Barranquero's message of "Wed, 30 Dec 2009 22:34:07 +0100")
On Wed, 30 Dec 2009 22:34:07 +0100, Juanma Barranquero <lekktu@gmail.com> wrote:
> Let's suppose I want to create a local post-23.2 branch where I do
> want to commit small changes to install on the trunk post-release. I
> don't want to be forced to create a task branch for every one of them,
> because they are small changes, and a new branch implies having to
> bootstrap[1] anew. So I'd like to accumulate the changes into a single
> branch.
>
> Once the trunk is open again, what would be the procedure to install
> the changes? Obviously not "bzr merge ../post-23.2", because that
> would create a single [merge] commit. Will I be forced to repeat "bzr
> log" and "bzr merge --revision=REVID ../post-23.2" for each change?
> That seems a bit cumbersome. Is there any way to simplify it? Perhaps
> a plugin?
Hi Juanma,
If the changes are separate commits, it *may* be simple to avoid a
gazillion merges (one for each small change) by using the rebase plugin
of bazaar. This way instead of having a history like
[1] [2] [3]
/ / /
o --- o --- o --- o --- o --- o
with 'o' revisions being trunk commits and local changes [1], [2] and
[3] forking from several different ancestor changesets, you can keep
your changes in a local branch like this
o --- o --- o --- o --- o --- o --- [1] --- [2] --- [3]
Every time you "bzr pull" from the trunk, you can re-rebase your local
changesets on top of the new trunk.
Without rebase, you would have to merge each one of [1], [2] and [3]
separately, resulting in a final history similar to:
[1] ----------------------------.
/ \
o --- o --- o --- o --- o --- o --- [m1] --- [m2] --- [m3]
\ \ / /
[2] [3] ------------ / --------'
\ /
`-----------------------'
with one merge changeset for each local patch. This is a moderately
complex history graph, that is mostly readable for three local changes,
but things quickly get messy with, say, upwards of 20 local patches.
The mostly linear history of rebased changesets is easier to read for
local patches. At least it is for me.
The good thing about keeping a local set of patches rebased to the
latest version of turnk is that you can start developing the patches
with revision N of the trunk:
o --- o --- [N] --- [1] --- [2]
then you cal pull as many times as necessary from the trunk (pull
revisions marked with '*' below:
o --- o --- [N] --- o --- * --- o --- o --- * --- [1] --- [2]
and keep the local patches rebased until they are 'done'. When they are
ready for trunk, you can simply "bzr push" them and stop rebasing the
local patches. They are not part of trunk and everyone will see them.
The down-sides of rebasing that I know of are:
(1) You cannot publish the rebased changesets and then rebase them
again. People who pulled the `old' rebase will still have it in
their local branch and you cannot do anything to delete *their*
local changes.
(2) Rebasing modifies the history but does not necessarily leave any
trace of the old state of the branch. So if you discover that you
botched the rebase or one of the merges that happened *during* the
rebase, you are screwed. Keeping a backup copy of the local
branch *before* a rebase operation (e.g. a tarball) is always a
good idea.
(3) Rebasing in a bound branch is probably a bad idea. I am not sure
how well the plugin will work with changes that are already pushed
to the remote side of a bound branch. It is very likely that it
will create a very messed up branch state both in the local and
the remote side of the world.
Having said that I've previously posted a, admittedly rather minimal,
example of instructions for the installation and the commands of the
bzr-rebase plugin at
<http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00871.html>.
It may be worth expanding on this if you think it would help you keep a
set of local-only patches until they are ready for the public trunk.
HTH,
Giorgos
next prev parent reply other threads:[~2009-12-30 22:54 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero
2009-12-30 21:37 ` Juanma Barranquero
2009-12-30 21:46 ` Óscar Fuentes
2009-12-30 23:57 ` Juanma Barranquero
2009-12-31 0:21 ` Óscar Fuentes
2009-12-31 0:27 ` Juanma Barranquero
2009-12-31 1:04 ` Óscar Fuentes
2009-12-31 1:33 ` Juanma Barranquero
2009-12-31 1:48 ` Óscar Fuentes
2009-12-31 2:22 ` Juanma Barranquero
2009-12-31 4:21 ` Eli Zaretskii
2009-12-31 4:36 ` Juanma Barranquero
2009-12-31 5:12 ` Miles Bader
2009-12-31 10:15 ` Eli Zaretskii
2009-12-31 10:44 ` Eli Zaretskii
2009-12-31 12:37 ` Juanma Barranquero
2009-12-31 19:44 ` Karl Fogel
2009-12-31 20:16 ` Eli Zaretskii
2009-12-31 20:41 ` Juanma Barranquero
2010-01-01 2:54 ` Richard Stallman
2010-01-01 12:35 ` Stephen J. Turnbull
2010-01-01 13:49 ` Stephen J. Turnbull
2009-12-31 5:06 ` Óscar Fuentes
2009-12-31 10:26 ` Eli Zaretskii
2009-12-31 12:28 ` Juanma Barranquero
2009-12-31 18:27 ` Eli Zaretskii
2009-12-31 18:59 ` Óscar Fuentes
2009-12-31 20:39 ` Juanma Barranquero
2010-01-01 13:53 ` Stephen J. Turnbull
2010-01-01 14:38 ` Eli Zaretskii
2009-12-30 22:54 ` Giorgos Keramidas [this message]
2009-12-31 0:11 ` Juanma Barranquero
2009-12-31 9:21 ` Andreas Schwab
2009-12-31 10:11 ` Eli Zaretskii
2009-12-31 11:44 ` Andreas Schwab
2009-12-31 12:23 ` Eli Zaretskii
2009-12-31 12:38 ` Juanma Barranquero
2009-12-31 13:25 ` Eli Zaretskii
2009-12-31 13:37 ` Juanma Barranquero
2009-12-31 14:13 ` Eli Zaretskii
2009-12-31 13:43 ` Giorgos Keramidas
2009-12-31 13:53 ` Juanma Barranquero
2009-12-31 14:07 ` Alfred M. Szmidt
2009-12-31 14:16 ` Juanma Barranquero
2010-01-01 15:38 ` Alfred M. Szmidt
2010-01-01 17:53 ` David Kastrup
2010-01-01 2:55 ` Richard Stallman
2010-01-01 4:03 ` Óscar Fuentes
2010-01-01 8:41 ` Eli Zaretskii
2010-01-01 10:04 ` Óscar Fuentes
2010-01-02 15:44 ` Richard Stallman
2010-01-01 12:19 ` Andreas Schwab
2010-01-01 14:33 ` Eli Zaretskii
2010-01-01 14:48 ` Andreas Schwab
2010-01-01 19:18 ` Karl Fogel
2010-01-01 19:56 ` Eli Zaretskii
2010-01-01 20:09 ` Chong Yidong
2010-01-01 21:34 ` Eli Zaretskii
2010-01-01 20:13 ` Karl Fogel
2010-01-01 21:35 ` Eli Zaretskii
2010-01-01 21:25 ` Óscar Fuentes
2010-01-01 21:34 ` Eli Zaretskii
2010-01-01 22:58 ` Andreas Schwab
2010-01-01 20:07 ` Teemu Likonen
2010-01-01 20:12 ` Karl Fogel
2010-01-01 21:08 ` Teemu Likonen
2010-01-02 5:00 ` Stephen J. Turnbull
2010-01-02 5:12 ` Karl Fogel
2010-01-02 5:24 ` Miles Bader
2010-01-02 11:43 ` Juanma Barranquero
2010-01-02 12:09 ` Miles Bader
2010-01-02 19:22 ` Karl Fogel
2010-01-05 8:50 ` Stephen J. Turnbull
2010-01-02 4:37 ` Stephen J. Turnbull
2010-01-01 14:59 ` Stephen J. Turnbull
2010-01-01 15:30 ` Eli Zaretskii
2010-01-01 15:38 ` Alfred M. Szmidt
2009-12-31 14:08 ` David Kastrup
2009-12-31 19:47 ` Karl Fogel
2009-12-31 20:14 ` Chong Yidong
2009-12-31 20:36 ` Óscar Fuentes
2009-12-31 20:44 ` Juanma Barranquero
2009-12-31 14:12 ` Eli Zaretskii
2009-12-31 19:08 ` Stefan Monnier
2009-12-31 12:20 ` Juanma Barranquero
2010-01-01 12:33 ` Stephen J. Turnbull
2010-01-02 1:56 ` Juanma Barranquero
2010-01-02 2:28 ` Óscar Fuentes
2010-01-02 2:50 ` Juanma Barranquero
2010-01-02 9:11 ` Eli Zaretskii
2010-01-02 13:20 ` Juanma Barranquero
2010-01-02 13:17 ` Juanma Barranquero
2010-01-02 3:46 ` Stephen J. Turnbull
2010-01-02 9:10 ` Eli Zaretskii
2010-01-02 15:30 ` Stephen J. Turnbull
2010-01-02 17:05 ` Eli Zaretskii
2010-01-02 13:39 ` Juanma Barranquero
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87637of4y8.fsf@kobe.laptop \
--to=keramida@ceid.upatras.gr \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.