From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Bzr taskbranches and ChangeLog
Date: Sat, 21 Dec 2013 09:44:41 +0100 [thread overview]
Message-ID: <87d2kqtwxy.fsf@thinkpad.tsdh.org> (raw)
In-Reply-To: <83vbyiaavn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Dec 2013 10:03:56 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
> As Xue pointed out, a large part of the solution is the
> changelog_merge plugin. With some bzr distributions, it comes
> bundled. It will do its job silently without you having to do
> anything at all.
>
> However, you need to remember one thing: changelog_merge puts the
> merged entries above (i.e., before) your local ones. So you will need
> to move them forward before committing to Savannah, because our commit
> policy is to have the ChangeLog entries in the (reverse) order of
> commits.
Ah ok, then it does work as it's supposed. I've read the "emit OTHERS
first" in its docs as if my changes were kept on top.
>> For example, I've just created a local branch bug-16090 which fixes that
>> bug. It's complete, but I want to wait with pushing until Stefan had a
>> look, so I'll surely need to merge from trunk some times.
>>
>> With git I would commit my changes (no ChangeLog entries right now)
>> locally, then keep rebasing onto master until Stefan gives his go, then
>> write the ChangeLog entry, commit that too, squash that commit with the
>> code change commit, and then push one single commit with the code and
>> ChangeLog changes.
>>
>> How do I do something similar with bzr?
>
> When I work on a feature branch, I usually don't write ChangeLog
> entries, only the commit messages. Then I merge to the trunk (a bound
> branch), test the changes there, write the ChangeLog entries there,
> and commit upstream. If someone commits between my merge to the trunk
> and commit to Savannah (whcih will require me to "bzr update" before
> committing upstream), and those commits touch the ChangeLog files
> where I added my entries, I move my ChangeLog entries to the top of
> the file before committing.
Ok, I see.
> First, while waiting for approval, you only need to merge from trunk
> if the changes there touch the files you modified, or if a lot of
> structural changes were made (like files deleted or renamed).
> Otherwise, no need to merge from trunk, just leave your branch alone
> until you get the approval to push. Bzr (like git and hg) is very
> good at merging, so no need for the "merge fever".
Ok, even better.
> And second, with the workflow I described above, the problems with
> ChangeLog are never a concern. Commit messages are good enough to
> keep the information about your work, if you need that later. In
> general, I find that I can write ChangeLog entries before the final
> commit upstream just by looking at the output of "bzr diff", and don't
> need to consult my commit messages, except in very rare cases. In
> fact, you can just walk the "bzr diff" hunks one by one in an Emacs
> buffer, and invoke "C-x 4 a" from there: Diff Mode usually does TRT
> with that.
Yes, that's what I've usually done, too.
Thanks,
Tassilo
next prev parent reply other threads:[~2013-12-21 8:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 20:50 Bzr taskbranches and ChangeLog Tassilo Horn
2013-12-21 1:16 ` Xue Fuqiao
2013-12-21 7:34 ` Tassilo Horn
2013-12-21 7:50 ` Tassilo Horn
2013-12-21 8:35 ` Eli Zaretskii
2013-12-23 8:15 ` Tassilo Horn
2013-12-21 8:03 ` Tassilo Horn
2013-12-21 8:43 ` Eli Zaretskii
2013-12-21 8:03 ` Eli Zaretskii
2013-12-21 8:44 ` Tassilo Horn [this message]
2013-12-21 8:49 ` Jarek Czekalski
2013-12-21 9:25 ` Eli Zaretskii
2013-12-21 13:32 ` Tassilo Horn
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=87d2kqtwxy.fsf@thinkpad.tsdh.org \
--to=tsdh@gnu.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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.