Re: GNU Emacs is on Bazaar now.

[Karl Fogel <kfogel@red-bean.com>]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>>>> > I followed that page and created "quickfixex" branch.
>>>>> It doesn't make sense to create a branch for every little commit.
>>> > No, I'm not going to do that.  I'll use that branch for
>>> > "One-Off Change" repeatedly.
>>> That's just the same.
>> ??? What is the same with what?
> Making a branch for every little commit.

What we have here is a failure to communicate :-).

Currently, BzrForEmacsDevs recommends keeping a 'trunk' branch (used for
merging from other branches and for committing to upstream, but never
used for development) and a 'quickfixes' branch (for quick little fixes,
where you don't want to have to create a whole new branch each time).

The document recommends that 'quickfixes' be treated like any other
non-trunk local branch: you keep it up-to-date, you commit changes
there, and when ready, you merge it into trunk and then commit in trunk.
The only thing special about it is that it persists basically forever --
unlike feature branches, which you usually remove when done.

So by using 'quickfixes', Kenichi is following the recommended
procedure.

A separate question is, is this a *good* procedure for quick fixes?

Kenichi has a point: for a simple typo fix, it's annoying to have to
commit it in quickfixes, and then go merge it into trunk and commit it
again (with its own log message beginning with "Merge: ").  It would be
easier to just make the change in trunk and commit from there.  However,
I wasn't sure what complications might arise from doing that ('trunk' is
a bound branch), so we recommended a very conservative, very safe
procedure.

We can certainly tweak the instructions, if they don't work well for
certain situations!  I just want to make sure we don't recommend any
methods that make it too easy to mess up history or shoot oneself in the
foot, that's all.  Does anyone know a better workflow for quick fixes?

-Karl