Re: Workflow to accumulate individual changes?

[Eli Zaretskii <eliz@gnu.org>]

> From: =?utf-8?Q?=C3=93scar_Fuentes?= <ofv@wanadoo.es>
> Date: Thu, 31 Dec 2009 06:06:51 +0100
> 
> > ChangeLog files will present a problem for feature branches and
> > quick-fix branches alike.
> 
> Very true. On Juanma's case, if he accumulated a signicant number of
> small changes, rebasing can save quite a bit of work compared to
> creating a patch, applying it, re-writing a commit message and commit
> for each change. Or merging one change, edit the ChangeLog, write the
> commit message, commit and repeat for the next change (which possibly is
> the most orthodox solution and recommendable if the amount of changes is
> moderate.)

It's an annoyance, yes, but not a large one.  After all, you have
everything right there in the same Emacs session.  How hard is it to
reorder a few log entries?

> > Though an annoyance, I don't see how it is a problem significant
> > enough to recommend rebase as the main vehicle of routine work, given
> > the downside of rebasing (rewriting history etc.).
> 
> The history is rewritten at Juanma's end. For the rest of users, the
> final result is indistinguishable of the case where Juanma commits a
> series of small changes on a fast sequence.

Unless I misunderstood what I've read, that's not accurate: the final
result _will_ matter for others, if and when those others will want at
some point in the future to dig into Juanma's changes and understand
how the final code came into existence -- which parts of it were
written by Juanma, which ones by others, and which ones are result of
bzr merges.  In fact, Juanma himself may wish to do this kind of
archeology some time after committing.

> The ChangeLog is a big incovenience for working locally while upstream
> access is restricted.

In my work on bidi Emacs, I keep a separate ChangeLog file precisely
for that reason.  With CVS, it was simply an unversioned file.  With
bzr, I will probably have it committed to my local branch, but will
delete it after copying (some of) its contents to the upstream logs
when the feature is merged with upstream.  If someone has a better
idea for a long-term feature branch, I'm all ears.