* Workflow to accumulate individual changes?
@ 2009-12-30 21:34 Juanma Barranquero
2009-12-30 21:37 ` Juanma Barranquero
` (3 more replies)
0 siblings, 4 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-30 21:34 UTC (permalink / raw
To: Emacs developers
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?
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
` (2 subsequent siblings)
3 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-30 21:37 UTC (permalink / raw
To: Emacs developers
On Wed, Dec 30, 2009 at 22:34, Juanma Barranquero <lekktu@gmail.com> wrote:
> bootstrap[1] anew. So I'd like to accumulate the changes into a single
I forgot the note, so:
[1] What does people do to create new branches and not having to do a
full bootstrap? A recursive copy of all *.o and *.elc files in the
parent branch? I know there's a plugin that helps with git-style
colocated branches, but I'm asking about using normal branches.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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-30 22:54 ` Giorgos Keramidas
2010-01-01 12:33 ` Stephen J. Turnbull
3 siblings, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-30 21:46 UTC (permalink / raw
To: emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> 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?
*IF* they are small changes, i.e., the sort of things that you would do
on the quickfixes branch, *AND* if you didn't merge with trunk, this
should work keeping the history nice:
<hack>
bzr commit
<hack>
bzr commit
...
<when post-release arrives>:
bzr rebase
bzr push
The resulting history on upstream will be linear, as if you committed
each change one by one on top of the previous one.
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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 22:54 ` Giorgos Keramidas
2009-12-31 0:11 ` Juanma Barranquero
2010-01-01 12:33 ` Stephen J. Turnbull
3 siblings, 1 reply; 97+ messages in thread
From: Giorgos Keramidas @ 2009-12-30 22:54 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-30 21:46 ` Óscar Fuentes
@ 2009-12-30 23:57 ` Juanma Barranquero
2009-12-31 0:21 ` Óscar Fuentes
` (2 more replies)
0 siblings, 3 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-30 23:57 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
On Wed, Dec 30, 2009 at 22:46, Óscar Fuentes <ofv@wanadoo.es> wrote:
> *IF* they are small changes, i.e., the sort of things that you would do
> on the quickfixes branch, *AND* if you didn't merge with trunk, this
> should work keeping the history nice:
>
> <hack>
> bzr commit
> <hack>
> bzr commit
> ...
> <when post-release arrives>:
> bzr rebase
> bzr push
>
> The resulting history on upstream will be linear, as if you committed
> each change one by one on top of the previous one.
If my post-23.2 branch is branched from my local trunk mirror, will
"bzr push" push to it? Will that work when trunk is a bound branch? Or
are you suggesting branching post-23.2 from
bzr.savannah.gnu.org/srv/bzr/emacs/trunk?
Anyway, after thinking about the issue, I'm not sure it'd work,
because of ChangeLog.
cd emacs
branch trunk post-23.2
cd post-23.2
# hack hack hack, including editing ChangeLog
# days pass
# 23.2 released
cd ../trunk
bzr update
cd ../post-23.2
bzr rebase
bzr push # ugh
# dates in ChangeLog are wrong, so you need an additional commit to
fix the ChangeLog entries
so it only really works for fixes that do not need ChangeLog entries.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-30 22:54 ` Giorgos Keramidas
@ 2009-12-31 0:11 ` Juanma Barranquero
2009-12-31 9:21 ` Andreas Schwab
0 siblings, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 0:11 UTC (permalink / raw
To: Giorgos Keramidas; +Cc: Emacs developers
On Wed, Dec 30, 2009 at 23:54, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:
> 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
Yes, thanks to both Óscar and you for the idea. Unfortunately, as I've
said, I think it does not mess too well with ChangeLog.
BTW, I'm interested in ways to deal with ChangeLog issues like this.
For example, if you spend a while developing a large side project on a
branch, your ChangeLog in that branch will reflect the dates of
individual changes. In the past, at the moment of merging the branch
back into the trunk, the dates were changed (most of unicode-2, or
multi-tty, were entered into the ChangeLog at the date the merge
happened). With Bazaar, we'd like to keep that kind of operation as a
single merge, so perhaps the last commit in the task branch will need
to be a ChangeLog fix with the day the merging is planned... Works,
but seems a bit messy.
I know it has been decided we still will maintain ChangeLogs, and I'm
not going to discuss it, but it's a bit of a pity, when a good commit
message policy and bzr log --gnu-changelog could save us the trouble.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
2010-01-01 13:53 ` Stephen J. Turnbull
2 siblings, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-31 0:21 UTC (permalink / raw
To: emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> On Wed, Dec 30, 2009 at 22:46, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> *IF* they are small changes, i.e., the sort of things that you would do
>> on the quickfixes branch, *AND* if you didn't merge with trunk, this
>> should work keeping the history nice:
>>
>> <hack>
>> bzr commit
>> <hack>
>> bzr commit
>> ...
>> <when post-release arrives>:
>> bzr rebase
>> bzr push
>>
>> The resulting history on upstream will be linear, as if you committed
>> each change one by one on top of the previous one.
>
> If my post-23.2 branch is branched from my local trunk mirror, will
> "bzr push" push to it?
You can provide a location:
bzr rebase URL
bzr push URL
> Will that work when trunk is a bound branch?
I do not recommend using your local mirror for that.
> Or are you suggesting branching post-23.2 from
> bzr.savannah.gnu.org/srv/bzr/emacs/trunk?
No, you can branch from your local mirror if you wish (and why
not?). Remember that a branch is an autonomous identity that can
communicate with any other branch.
> Anyway, after thinking about the issue, I'm not sure it'd work,
> because of ChangeLog.
[snip]
> so it only really works for fixes that do not need ChangeLog entries.
Yup. This requires editing before sending upstream, so the most you can
do is to use a bzr branch as a patch depot.
Other option for having a patch depot is to use `bzr shelve', then when
you can commit unshelve each change separately, edit Changelog, commit
it... It seems as feature abuse to me, but it can be manageable if the
amount of changes is small and don't overlap.
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 0:21 ` Óscar Fuentes
@ 2009-12-31 0:27 ` Juanma Barranquero
0 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 0:27 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
On Thu, Dec 31, 2009 at 01:21, Óscar Fuentes <ofv@wanadoo.es> wrote:
> You can provide a location:
>
> bzr rebase URL
> bzr push URL
[...]
> No, you can branch from your local mirror if you wish (and why
> not?). Remember that a branch is an autonomous identity that can
> communicate with any other branch.
I understand that. I though you were saying that "bzr push" (without
URL) would work in this case.
> Yup. This requires editing before sending upstream, so the most you can
> do is to use a bzr branch as a patch depot.
Yes, I see :( Well, it's still better than having to branch for each
small change.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-30 23:57 ` Juanma Barranquero
2009-12-31 0:21 ` Óscar Fuentes
@ 2009-12-31 1:04 ` Óscar Fuentes
2009-12-31 1:33 ` Juanma Barranquero
2010-01-01 13:53 ` Stephen J. Turnbull
2 siblings, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-31 1:04 UTC (permalink / raw
To: emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> Anyway, after thinking about the issue, I'm not sure it'd work,
> because of ChangeLog.
[snip]
> # dates in ChangeLog are wrong, so you need an additional commit to
> fix the ChangeLog entries
>
> so it only really works for fixes that do not need ChangeLog entries.
Thinking a bit more about this...
`rebase' stops if it finds conflicts, then you need to resolve the
conflicts (i.e. edit the conflicted changes) and continue the rebase.
If somehow the rebase finds a conflict on the ChangeLog for every
rebased revision, you could fix the dates. I know by experience that
Subversion generates a conflict every time two changes append lines to a
file. If bzr generates a conflict when two changes happen at the top of
the ChangeLog file, you could arrange things for this to happen: the
first revision should conflict right away; for the second revision to
conflict, you'll need to leave the top of the ChangeLog on a way that it
can't merge the second revision, etc.
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 1:04 ` Óscar Fuentes
@ 2009-12-31 1:33 ` Juanma Barranquero
2009-12-31 1:48 ` Óscar Fuentes
2009-12-31 4:21 ` Eli Zaretskii
0 siblings, 2 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 1:33 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
On Thu, Dec 31, 2009 at 02:04, Óscar Fuentes <ofv@wanadoo.es> wrote:
> If somehow the rebase finds a conflict on the ChangeLog for every
> rebased revision, you could fix the dates. I know by experience that
> Subversion generates a conflict every time two changes append lines to a
> file. If bzr generates a conflict when two changes happen at the top of
> the ChangeLog file, you could arrange things for this to happen: the
> first revision should conflict right away; for the second revision to
> conflict, you'll need to leave the top of the ChangeLog on a way that it
> can't merge the second revision, etc.
I'd rather have Bazaar not to generate a conflict for changes at the
top of the file; it's common enough, and I've had my share of them on
CVS :-)
That said, what you propose could work, but of course it's quite
hackish. Let's hope someday the rebase plugin will grow an option to
rebase interactively, stopping before the commit.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
1 sibling, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-31 1:48 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
>> If somehow the rebase finds a conflict on the ChangeLog for every
>> rebased revision, you could fix the dates. I know by experience that
>> Subversion generates a conflict every time two changes append lines to a
>> file. If bzr generates a conflict when two changes happen at the top of
>> the ChangeLog file, you could arrange things for this to happen: the
>> first revision should conflict right away; for the second revision to
>> conflict, you'll need to leave the top of the ChangeLog on a way that it
>> can't merge the second revision, etc.
>
> I'd rather have Bazaar not to generate a conflict for changes at the
> top of the file; it's common enough, and I've had my share of them on
> CVS :-)
>
> That said, what you propose could work, but of course it's quite
> hackish.
It works and yes, it is hackish :-) Just make sure that after every
conflict resolve the first line of the ChangeLog differs from the first
line of the next revision.
> Let's hope someday the rebase plugin will grow an option to
> rebase interactively, stopping before the commit.
There is a big chance that adding that feature is very easy, and plugins
are not under the very strict development policy of Bazaar, so submit a
feature request to the plugin tracker:
https://launchpad.net/bzr-rewrite
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 1:48 ` Óscar Fuentes
@ 2009-12-31 2:22 ` Juanma Barranquero
0 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 2:22 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
On Thu, Dec 31, 2009 at 02:48, Óscar Fuentes <ofv@wanadoo.es> wrote:
> It works and yes, it is hackish :-) Just make sure that after every
> conflict resolve the first line of the ChangeLog differs from the first
> line of the next revision.
Well, I'll give it a try. Thanks for looking into it.
> so submit a
> feature request to the plugin tracker:
>
> https://launchpad.net/bzr-rewrite
Will do right now.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 1:33 ` Juanma Barranquero
2009-12-31 1:48 ` Óscar Fuentes
@ 2009-12-31 4:21 ` Eli Zaretskii
2009-12-31 4:36 ` Juanma Barranquero
2009-12-31 5:06 ` Óscar Fuentes
1 sibling, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 4:21 UTC (permalink / raw
To: Juanma Barranquero; +Cc: ofv, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 02:33:39 +0100
> Cc: emacs-devel@gnu.org
>
> That said, what you propose could work, but of course it's quite
> hackish. Let's hope someday the rebase plugin will grow an option to
> rebase interactively, stopping before the commit.
Except that most experts on bzr I've read say rebasing is the wrong
way to go[1]. So I think we should not flee to that corner so easily,
upon bumping on the first problematic issue.
ChangeLog files will present a problem for feature branches and
quick-fix branches alike. 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.).
Am I missing something?
---------------
[1] http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:44 ` Eli Zaretskii
2009-12-31 5:06 ` Óscar Fuentes
1 sibling, 2 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 4:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, emacs-devel
On Thu, Dec 31, 2009 at 05:21, Eli Zaretskii <eliz@gnu.org> wrote:
> Except that most experts on bzr I've read say rebasing is the wrong
> way to go[1].
Personally, and with all due respect, I don't consider this: "There
are many theoretical objections to rebasing, and I won’t rehash them
here. There’s general consensus that rebasing is sort of icky." as a
sort of expert opinion, just biased. People used to git's rebase find
it extremely useful. And, in fact, this other bit:
> “Why isn’t rebase support in core?” Rebase support is currently packaged
> as a plugin. This plugin is widely distributed, even in the standard Mac OS
> X installation bundle.
isn't exactly true anymore, as it is also included at least in the
standard Windows standalone installation.
> So I think we should not flee to that corner so easily,
> upon bumping on the first problematic issue.
We're not fleeing into any corner. Weren't I thinking that ChangeLog
present problems that should be discussed, I wouldn't have brought the
issue.
> ChangeLog files will present a problem for feature branches and
> quick-fix branches alike. 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.).
>
> Am I missing something?
Yes. Neither of us is "recommending rebase as the main vehicle of
routine work". I was talking very specifically of a workflow I intend
to use, but I have no idea how common it'll be for other people; and
for my use, an interactive rebase would be a perfect option. I
wouldn't dream of suggest Karl to discuss rebase on BzrForEmacsDevs,
for example.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 4:21 ` Eli Zaretskii
2009-12-31 4:36 ` Juanma Barranquero
@ 2009-12-31 5:06 ` Óscar Fuentes
2009-12-31 10:26 ` Eli Zaretskii
2009-12-31 18:27 ` Eli Zaretskii
1 sibling, 2 replies; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-31 5:06 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> That said, what you propose could work, but of course it's quite
>> hackish. Let's hope someday the rebase plugin will grow an option to
>> rebase interactively, stopping before the commit.
>
> Except that most experts on bzr I've read say rebasing is the wrong
> way to go[1].
It often is. In *this* case it is not wrong nor right. It is just what
does the job. Please note the big IFs in my answer to Juanma.
> So I think we should not flee to that corner so easily, upon bumping
> on the first problematic issue.
Agreed. If anyone thinks that rebase it the solution for his problem,
please ask here first.
> 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.)
> 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.
> Am I missing something?
Yes. That `goto' is evil but sometimes it has its uses :-)
I concede that rebase here can be questionable as the most efficient or
dumb-proof solution (you have to be very careful or the whole process
can be ruined and repeated; it is strongly advised to backup your branch
first.)
The ChangeLog is a big incovenience for working locally while upstream
access is restricted. I hope that after some time, people will
experience the fact that a ChangeLog is completely redundant on a
changeset-based VCS.
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
1 sibling, 1 reply; 97+ messages in thread
From: Miles Bader @ 2009-12-31 5:12 UTC (permalink / raw
To: Juanma Barranquero; +Cc: ofv, Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
>> Except that most experts on bzr I've read say rebasing is the wrong
>> way to go[1].
>
> Personally, and with all due respect, I don't consider this: "There
> are many theoretical objections to rebasing, and I won’t rehash them
> here. There’s general consensus that rebasing is sort of icky." as a
> sort of expert opinion, just biased. People used to git's rebase find
> it extremely useful.
Yup. Rebasing rocks, especially interactive rebasing.
To be honest, a huge amount of bzr docs and commentary seems to be
essentially bzr apologia trying to compensate for technical failings in
bzr by saying "ok, so bzr doesn't do that as well as the competition,
but you didn't really want to do that anyway... trust us..."
-Miles
--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like. Otherwise the
programs they write will be pretty weird. -- Donald Knuth
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 0:11 ` Juanma Barranquero
@ 2009-12-31 9:21 ` Andreas Schwab
2009-12-31 10:11 ` Eli Zaretskii
2009-12-31 12:20 ` Juanma Barranquero
0 siblings, 2 replies; 97+ messages in thread
From: Andreas Schwab @ 2009-12-31 9:21 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Giorgos Keramidas, Emacs developers
Juanma Barranquero <lekktu@gmail.com> writes:
> I know it has been decided we still will maintain ChangeLogs, and I'm
> not going to discuss it, but it's a bit of a pity, when a good commit
> message policy and bzr log --gnu-changelog could save us the trouble.
ChangeLog entries and commit messages serve a different purpose.
ChangeLog entries describe the "physical" changes, a commit message the
"logical" change. That is, the commit message describes the changeset
on a higher level than the ChangeLog entries. As such it does not make
sense to repeat the ChangeLog entries in the commit message.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:20 ` Juanma Barranquero
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 10:11 UTC (permalink / raw
To: Andreas Schwab; +Cc: keramida, lekktu, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Thu, 31 Dec 2009 10:21:05 +0100
> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>,
> Emacs developers <emacs-devel@gnu.org>
>
> ChangeLog entries and commit messages serve a different purpose.
> ChangeLog entries describe the "physical" changes, a commit message the
> "logical" change. That is, the commit message describes the changeset
> on a higher level than the ChangeLog entries. As such it does not make
> sense to repeat the ChangeLog entries in the commit message.
I agree with the principle (and I think most, if not all, of others do
as well). But what does this mean in practice? Are you suggesting
that the commit message should not mention the changes in individual
files at all, just the general idea?
If that's not what you suggest, i.e. if changes in individual files
_should_ be mentioned, it will be very hard to resist the temptation
of copying the ChangeLog entries, perhaps _in_addition_to_ the
high-level description that we already asked to provide, a couple of
weeks ago.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 5:12 ` Miles Bader
@ 2009-12-31 10:15 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 10:15 UTC (permalink / raw
To: Miles Bader; +Cc: ofv, lekktu, emacs-devel
> From: Miles Bader <miles@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org
> Reply-To: Miles Bader <miles@gnu.org>
> System-Type: x86_64-unknown-linux-gnu
> Date: Thu, 31 Dec 2009 14:12:15 +0900
>
> To be honest, a huge amount of bzr docs and commentary seems to be
> essentially bzr apologia trying to compensate for technical failings in
> bzr by saying "ok, so bzr doesn't do that as well as the competition,
> but you didn't really want to do that anyway... trust us..."
Except that not only the documentation says that, the most active bzr
developers say that as well. Maybe you know enough about bzr to
decide that it's FUD or cheap marketing, but I'm willing to try the
recommended way first, before I decide otherwise based on problems I
bump into (if and when).
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 10:26 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 4:36 ` Juanma Barranquero
2009-12-31 5:12 ` Miles Bader
@ 2009-12-31 10:44 ` Eli Zaretskii
2009-12-31 12:37 ` Juanma Barranquero
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 10:44 UTC (permalink / raw
To: Juanma Barranquero; +Cc: ofv, emacs-devel
From: Eli Zaretskii <eliz@gnu.org>
To: Juanma Barranquero <lekktu@gmail.com>
CC: ofv@wanadoo.es, emacs-devel@gnu.org
In-reply-to: <f7ccd24b0912302036y51436f47p164fe640f926cfb7@mail.gmail.com>
(message from Juanma Barranquero on Thu, 31 Dec 2009 05:36:30 +0100)
Subject: Re: Workflow to accumulate individual changes?
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <f7ccd24b0912301334u6df4cf24k7625713ba8e4252@mail.gmail.com>
<87fx6sm8yl.fsf@telefonica.net> <f7ccd24b0912301557s7e40ab26h8ee88c630757c1ce@mail.gmail.com>
<873a2slzrr.fsf@telefonica.net> <f7ccd24b0912301733k510c6bbaub97223dcf2565055@mail.gmail.com>
<83ws03db8v.fsf@gnu.org> <f7ccd24b0912302036y51436f47p164fe640f926cfb7@mail.gmail.com>
--text follows this line--
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 05:36:30 +0100
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
>
> Personally, and with all due respect, I don't consider this: "There
> are many theoretical objections to rebasing, and I won’t rehash them
> here. There’s general consensus that rebasing is sort of icky." as a
> sort of expert opinion, just biased.
Me neither. I'm talking about the rest of the reasons, which _are_
described in detail.
> People used to git's rebase find it extremely useful.
I don't know anything about git, so I cannot talk about this. Just
remember that Stephen pointed to a posting by Linus who very
eloquently explained how rebasing is a bad idea in at least one
situation.
> Weren't I thinking that ChangeLog present problems that should be
> discussed, I wouldn't have brought the issue.
If ChangeLog maintenance is such a big problem, I think we should
resolve it here and now. Otherwise, it's a tail wagging the dog.
> > ChangeLog files will present a problem for feature branches and
> > quick-fix branches alike. 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.).
> >
> > Am I missing something?
>
> Yes. Neither of us is "recommending rebase as the main vehicle of
> routine work". I was talking very specifically of a workflow I intend
> to use, but I have no idea how common it'll be for other people; and
> for my use, an interactive rebase would be a perfect option. I
> wouldn't dream of suggest Karl to discuss rebase on BzrForEmacsDevs,
> for example.
ChangeLog's are part of everyone's workflow (unless we decide to stop
using them). If we think ChangeLog's are causing significant
inconveniences that are not addressed in the recommended workflow, and
if rebasing is the recommended solution for that, then we had better
address these issues now, and by all means mention them on the wiki.
IOW, what annoys Juanma Barranquero, will probably annoy a few more,
so I would not dismiss that as Juanma's private problems whose
solution concerns no one but Juanma ;-)
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 10:11 ` Eli Zaretskii
@ 2009-12-31 11:44 ` Andreas Schwab
2009-12-31 12:23 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Andreas Schwab @ 2009-12-31 11:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: keramida, lekktu, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Are you suggesting that the commit message should not mention the
> changes in individual files at all, just the general idea?
Yes, that's what they are for. Just like a merge commit does not repeat
the history of all merged revisions, but just summerizes it.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 9:21 ` Andreas Schwab
2009-12-31 10:11 ` Eli Zaretskii
@ 2009-12-31 12:20 ` Juanma Barranquero
1 sibling, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 12:20 UTC (permalink / raw
To: Andreas Schwab; +Cc: Giorgos Keramidas, Emacs developers
On Thu, Dec 31, 2009 at 10:21, Andreas Schwab <schwab@linux-m68k.org> wrote:
> ChangeLog entries and commit messages serve a different purpose.
> ChangeLog entries describe the "physical" changes, a commit message the
> "logical" change. That is, the commit message describes the changeset
> on a higher level than the ChangeLog entries. As such it does not make
> sense to repeat the ChangeLog entries in the commit message.
We have plenty of ChangeLog entries that describe both, because it is
(or it was, with CVS) much easier/faster to look at the ChangeLog than
the cvs log. And most projects do survive withouth ChangeLogs, by
using the commit logs, and having a good interface to the VCS to make
the diffs easy to access. I think your distinction is theoretically
sound, but as a policy difficult to implement.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:43 ` Giorgos Keramidas
0 siblings, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 12:23 UTC (permalink / raw
To: Andreas Schwab; +Cc: keramida, lekktu, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org
> Date: Thu, 31 Dec 2009 12:44:46 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Are you suggesting that the commit message should not mention the
> > changes in individual files at all, just the general idea?
>
> Yes, that's what they are for.
But then the corresponding ChangeLog entries should have the text
identical or very similar to the commit message in front of them, or
else have some other means of locating the log entries easily.
Anyway, I'm okay with this policy, if Stefan and Yidong approve it.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 10:26 ` Eli Zaretskii
@ 2009-12-31 12:28 ` Juanma Barranquero
0 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 12:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
On Thu, Dec 31, 2009 at 11:26, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.
No. We're discussing small patches, every one of them a single commit,
all of them unrelated. Once I push the changes, the past is
irrelevant. My using a private branch and rebase would be utterly
indistinguishable of my having developed and committed each one on the
trunk/ (as some are suggesting for such quickfixes).
rebase is a tool to keep private history private, and public history
clean. Nothing more, nothing less.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 10:44 ` Eli Zaretskii
@ 2009-12-31 12:37 ` Juanma Barranquero
2009-12-31 19:44 ` Karl Fogel
0 siblings, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 12:37 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, emacs-devel
On Thu, Dec 31, 2009 at 11:44, Eli Zaretskii <eliz@gnu.org> wrote:
> Me neither. I'm talking about the rest of the reasons, which _are_
> described in detail.
Please! The document does not show real arguments against rebase, just
"questions about the necessity of rebasing in typical workflows", from
the perspective of people who do not have or like rebase. For the
opposite perspective, just look for a few happy git users.
> I don't know anything about git, so I cannot talk about this. Just
> remember that Stephen pointed to a posting by Linus who very
> eloquently explained how rebasing is a bad idea in at least one
> situation.
Of course. Every user of rebase knows that: you shouldn't rebase a
public branch (and even that is OK in cases where the users know that
rebasing will be done). But here we were discussing *private*
rebasing.
> If ChangeLog maintenance is such a big problem, I think we should
> resolve it here and now. Otherwise, it's a tail wagging the dog.
Not a big problem, a small but repeated inconvencience.
> IOW, what annoys Juanma Barranquero, will probably annoy a few more,
> so I would not dismiss that as Juanma's private problems whose
> solution concerns no one but Juanma ;-)
Well, I can agree with that if you can agree that perhaps rebase
*could be* the best fix after all... ;-)
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:43 ` Giorgos Keramidas
1 sibling, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 12:38 UTC (permalink / raw
To: Eli Zaretskii; +Cc: keramida, Andreas Schwab, emacs-devel
On Thu, Dec 31, 2009 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote:
> Anyway, I'm okay with this policy, if Stefan and Yidong approve it.
I'm not, unless Stefan and Yidong force it.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 12:38 ` Juanma Barranquero
@ 2009-12-31 13:25 ` Eli Zaretskii
2009-12-31 13:37 ` Juanma Barranquero
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 13:25 UTC (permalink / raw
To: Juanma Barranquero; +Cc: keramida, schwab, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 13:38:16 +0100
> Cc: Andreas Schwab <schwab@linux-m68k.org>, keramida@ceid.upatras.gr, emacs-devel@gnu.org
>
> On Thu, Dec 31, 2009 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Anyway, I'm okay with this policy, if Stefan and Yidong approve it.
>
> I'm not, unless Stefan and Yidong force it.
Please tell why not, perhaps I'll change my mind ;-)
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 13:25 ` Eli Zaretskii
@ 2009-12-31 13:37 ` Juanma Barranquero
2009-12-31 14:13 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 13:37 UTC (permalink / raw
To: Eli Zaretskii; +Cc: keramida, schwab, emacs-devel
On Thu, Dec 31, 2009 at 14:25, Eli Zaretskii <eliz@gnu.org> wrote:
> Please tell why not, perhaps I'll change my mind ;-)
It's already been said it, I think. Theoretically, ChangeLog is for
"physical" changes, and the commit log is for "logical" changes, as
Andreas pointed out. But that is difficult to enforce; so in order to
understand a given change, you already have to look at both (and,
sometimes, you *need* both to understand what's happened). It's better
IMO to put all relevant info together, even if that means duplicating
it. And that will ease the switch to a ChangeLog-less future, if and
when we someday decide that it is not really useful to maintain the
ChangeLogs anymore.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 12:23 ` Eli Zaretskii
2009-12-31 12:38 ` Juanma Barranquero
@ 2009-12-31 13:43 ` Giorgos Keramidas
2009-12-31 13:53 ` Juanma Barranquero
` (3 more replies)
1 sibling, 4 replies; 97+ messages in thread
From: Giorgos Keramidas @ 2009-12-31 13:43 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, Andreas Schwab, emacs-devel
On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org
>> Date: Thu, 31 Dec 2009 12:44:46 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Are you suggesting that the commit message should not mention the
>> > changes in individual files at all, just the general idea?
>>
>> Yes, that's what they are for.
>
> But then the corresponding ChangeLog entries should have the text
> identical or very similar to the commit message in front of them, or
> else have some other means of locating the log entries easily.
>
> Anyway, I'm okay with this policy, if Stefan and Yidong approve it.
I think it's very useful to see file changes in the ChangeLog. It helps
a lot when an Emacs user downloads a tarball of the sources from the FTP
site, because file changes are visible without full access to the
original branch itself or access to a bzr client.
Maybe we can try to strike a balance between not keeping the ChangeLog
up to date at all and making it difficult to commit *one* changeset that
includes both ChangeLog updates _and_ file updates by committing the
ChangeLog updates separately? This way, we can have a very short
summary in the ChangeLog commit, e.g.:
: keramida@kobe:/tmp/bzrdemo$ cat ChangeLog
: 2009-12-31 Giorgos Keramidas <keramida@ceid.upatras.gr>
:
: * foo: Add a new 'foo' file.
:
: keramida@kobe:/tmp/bzrdemo$ bzr log --show-ids
: ------------------------------------------------------------
: revno: 2
: revision-id: keramida@ceid.upatras.gr-20091231133847-f7og1ku98r1ng019
: parent: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1
: committer: Giorgos Keramidas <keramida@ceid.upatras.gr>
: branch nick: bzrdemo
: timestamp: Thu 2009-12-31 15:38:47 +0200
: message:
: ChangeLog for keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1
: ------------------------------------------------------------
: revno: 1
: revision-id: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1
: committer: Giorgos Keramidas <keramida@ceid.upatras.gr>
: branch nick: bzrdemo
: timestamp: Thu 2009-12-31 15:36:56 +0200
: message:
: Add a new 'foo' file.
:
: keramida@kobe:/tmp/bzrdemo$
To avoid doubling the revisions we keep in the repository, by following
*every* single commit with a ChangeLog update, we can batch ChangeLog
updates. So a developer can work in his own local branch and commit
several local changes before updating the ChangeLog. Then a single
ChangeLog commit on top of those can be stacked on top of the batch of
local changes, right before they are pushed to the trunk.
In a related side-node, it seems vc-update-change-log doesn't grok bzr
branches. What are the missing bits? Can we add them now that Emacs
itself uses bzr?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:08 ` David Kastrup
` (2 subsequent siblings)
3 siblings, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 13:53 UTC (permalink / raw
To: Giorgos Keramidas; +Cc: Eli Zaretskii, Andreas Schwab, emacs-devel
On Thu, Dec 31, 2009 at 14:43, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:
> I think it's very useful to see file changes in the ChangeLog. It helps
> a lot when an Emacs user downloads a tarball of the sources from the FTP
> site, because file changes are visible without full access to the
> original branch itself or access to a bzr client.
If we were using the commit log to put ChangeLog entries, the
ChangeLog could be reconstructed as part of making the release tarball
by a simple
bzr log --gnu-changelog -r ...
> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset that
> includes both ChangeLog updates _and_ file updates by committing the
> ChangeLog updates separately?
That breaks the idea that commits should try to respect the ACID
(atomicity, consistency, isolation, durability) principle.
> To avoid doubling the revisions we keep in the repository, by following
> *every* single commit with a ChangeLog update, we can batch ChangeLog
> updates. So a developer can work in his own local branch and commit
> several local changes before updating the ChangeLog. Then a single
> ChangeLog commit on top of those can be stacked on top of the batch of
> local changes, right before they are pushed to the trunk.
Personally, I find this idea ugly.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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 2:55 ` Richard Stallman
0 siblings, 2 replies; 97+ messages in thread
From: Alfred M. Szmidt @ 2009-12-31 14:07 UTC (permalink / raw
To: Juanma Barranquero; +Cc: keramida, eliz, schwab, emacs-devel
A major problem with generating the ChangeLog from the commit messages
is that you cannot fix a incorrect entry. More often than not, you
need to do fixes (forgotten entries, incorrect formating, ...).
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 13:43 ` Giorgos Keramidas
2009-12-31 13:53 ` Juanma Barranquero
@ 2009-12-31 14:08 ` David Kastrup
2009-12-31 19:47 ` Karl Fogel
2009-12-31 14:12 ` Eli Zaretskii
2009-12-31 19:08 ` Stefan Monnier
3 siblings, 1 reply; 97+ messages in thread
From: David Kastrup @ 2009-12-31 14:08 UTC (permalink / raw
To: emacs-devel
Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> I think it's very useful to see file changes in the ChangeLog. It
> helps a lot when an Emacs user downloads a tarball of the sources from
> the FTP site, because file changes are visible without full access to
> the original branch itself or access to a bzr client.
_IF_ the file change history is important, we can generate it on the
source web page on the fly, from the VCS logs. ChangeLog dates from a
time of VCS-less development. If we really want to distribute this sort
of info, generating it from commits is quite more reliable.
One point of a distributed version control system is that non-privileged
users may clone their own repository and have all this historical data
in case they need to work with it.
My vote is for moving ChangeLog maintenance to proper commit message
maintenance: that is more important for a developer with version control
access, and again, DVCS use means that this info is available off-line
to the user/programmer. With CVS, it wasn't.
> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset
> that includes both ChangeLog updates _and_ file updates by committing
> the ChangeLog updates separately?
I don't consider it useful anymore to artificially split relevant change
info between ChangeLog and commit messages: all relevant version control
tools (graphical browsers etc) access the commit messages, and those are
there also offline.
There is no info we want in ChangeLog that should be missing from commit
messages.
The price Emacs developers pay for following the proposed hair-splitting
policies now is too high. With CVS, off-line access to the ChangeLog
was a somewhat valid argument. With DVCS, it isn't.
--
David Kastrup
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 13:43 ` Giorgos Keramidas
2009-12-31 13:53 ` Juanma Barranquero
2009-12-31 14:08 ` David Kastrup
@ 2009-12-31 14:12 ` Eli Zaretskii
2009-12-31 19:08 ` Stefan Monnier
3 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 14:12 UTC (permalink / raw
To: Giorgos Keramidas; +Cc: lekktu, schwab, emacs-devel
> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, lekktu@gmail.com,
> emacs-devel@gnu.org
> Date: Thu, 31 Dec 2009 15:43:57 +0200
>
> On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org
> >> Date: Thu, 31 Dec 2009 12:44:46 +0100
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > Are you suggesting that the commit message should not mention the
> >> > changes in individual files at all, just the general idea?
> >>
> >> Yes, that's what they are for.
> >
> > But then the corresponding ChangeLog entries should have the text
> > identical or very similar to the commit message in front of them, or
> > else have some other means of locating the log entries easily.
>
> I think it's very useful to see file changes in the ChangeLog.
The issue at hand is whether to have them in the commit messages, not
in ChangeLog. ChangeLog entries always include file and function
information, it's been like that since day one.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 13:37 ` Juanma Barranquero
@ 2009-12-31 14:13 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 14:13 UTC (permalink / raw
To: Juanma Barranquero; +Cc: keramida, schwab, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 14:37:21 +0100
> Cc: schwab@linux-m68k.org, keramida@ceid.upatras.gr, emacs-devel@gnu.org
>
> It's better IMO to put all relevant info together, even if that
> means duplicating it.
I don't mind that, either.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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 2:55 ` Richard Stallman
1 sibling, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 14:16 UTC (permalink / raw
To: ams; +Cc: keramida, eliz, schwab, emacs-devel
On Thu, Dec 31, 2009 at 15:07, Alfred M. Szmidt <ams@gnu.org> wrote:
> A major problem with generating the ChangeLog from the commit messages
> is that you cannot fix a incorrect entry. More often than not, you
> need to do fixes (forgotten entries, incorrect formating, ...).
I know, I've done quite a few changes to old ChangeLog entries :-)
Still, that seems to me a lesser problem that having to check two
places to get all relevant info. And, if you look deep at our
ChangeLogs, after years and years of use I'm sure you wouldn't take
more than half an hour to find some mistake (I'm not talking about
typos, but missing, wrong or duplicate entries, etc.). At the end of
the day, you look at the ChangeLog or the commit message to get an
idea of what happened; if you need the full info, there's the diffs.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 5:06 ` Óscar Fuentes
2009-12-31 10:26 ` Eli Zaretskii
@ 2009-12-31 18:27 ` Eli Zaretskii
2009-12-31 18:59 ` Óscar Fuentes
2009-12-31 20:39 ` Juanma Barranquero
1 sibling, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 18:27 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Thu, 31 Dec 2009 06:06:51 +0100
>
> If anyone thinks that rebase it the solution for his problem, please
> ask here first.
So what problem was it in this case, for which rebase is a solution?
Is it the case of a number of small unrelated changes that somehow
accumulated in the local branch? Or is it something else?
It cannot be a single coherent change, because for that, we still
think the workflow described on the wiki for the quickfixes branch is
the recommended way to go, right?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 18:27 ` Eli Zaretskii
@ 2009-12-31 18:59 ` Óscar Fuentes
2009-12-31 20:39 ` Juanma Barranquero
1 sibling, 0 replies; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-31 18:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> If anyone thinks that rebase it the solution for his problem, please
>> ask here first.
>
> So what problem was it in this case, for which rebase is a solution?
It was considered as a hack for editing the ChangeLog dates of old local
commits before sending them upstream.
> Is it the case of a number of small unrelated changes that somehow
> accumulated in the local branch?
Yes, it is about sending upstream a series of small changes that you
accumulated on a branch (because you had no net access of because
commits to upstream were temporarily restricted for whatever reason.)
There are two problems with this: first, merging the ChangeLog entries
correctly (mainly updating dates) and second, not having to merge and
commit all those changes one by one.
If you agree that the quickfixes->merge-to-trunk->commit workflow is the
right thing, you don't need rebase here: you have to merge and commit to
upstream each change individually and you can edit the ChangeLog at that
point.
If you think that having to merge a small change is an unnecessary
burden and prefer to commit directly to upstream, rebase is the solution
but the ChangeLog is on the way forcing you to resort to a hack for
editing it. If it no were ChangeLog, sending upstream that series of
small changes would need just two commands (rebase & push).
The general issue here is the impact the ChangeLog has on off-line
working, including into the concept of off-line feature branches that
live for more than a day.
[snip]
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 13:43 ` Giorgos Keramidas
` (2 preceding siblings ...)
2009-12-31 14:12 ` Eli Zaretskii
@ 2009-12-31 19:08 ` Stefan Monnier
3 siblings, 0 replies; 97+ messages in thread
From: Stefan Monnier @ 2009-12-31 19:08 UTC (permalink / raw
To: Giorgos Keramidas; +Cc: lekktu, Eli Zaretskii, Andreas Schwab, emacs-devel
> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset that
> includes both ChangeLog updates _and_ file updates by committing the
> ChangeLog updates separately? This way, we can have a very short
> summary in the ChangeLog commit, e.g.:
No, don't. It's very simple to do it in a single commit: use C-x 4 a as
usual to write the ChangeLog, then use C-c C-a in the *vc-commit* buffer
to pull the ChangeLog text and then C-c C-c to do the commit of all the
files (including the ChangeLog).
The text is duplicated but written only once and that's what counts.
We may reconsider this in the future by dropping the ChangeLog file
(aka auto-constructing it from the commit logs), but not now.
Stefan
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 12:37 ` Juanma Barranquero
@ 2009-12-31 19:44 ` Karl Fogel
2009-12-31 20:16 ` Eli Zaretskii
` (3 more replies)
0 siblings, 4 replies; 97+ messages in thread
From: Karl Fogel @ 2009-12-31 19:44 UTC (permalink / raw
To: Juanma Barranquero; +Cc: ofv, Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
>> IOW, what annoys Juanma Barranquero, will probably annoy a few more,
>> so I would not dismiss that as Juanma's private problems whose
>> solution concerns no one but Juanma ;-)
>
>Well, I can agree with that if you can agree that perhaps rebase
>*could be* the best fix after all... ;-)
I've never used 'bzr rebase', and have no competency to evaluate the
arguments either way here, but... wouldn't something would smell fishy
if rebase were part of our regular workflow? That somehow seems wrong.
If we find we're about to recommend that, please ask on the Bazaar list
first (maybe you have already).
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 14:08 ` David Kastrup
@ 2009-12-31 19:47 ` Karl Fogel
2009-12-31 20:14 ` Chong Yidong
0 siblings, 1 reply; 97+ messages in thread
From: Karl Fogel @ 2009-12-31 19:47 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
David Kastrup <dak@gnu.org> writes:
>_IF_ the file change history is important, we can generate it on the
>source web page on the fly, from the VCS logs. ChangeLog dates from a
>time of VCS-less development. If we really want to distribute this sort
>of info, generating it from commits is quite more reliable.
>
>One point of a distributed version control system is that non-privileged
>users may clone their own repository and have all this historical data
>in case they need to work with it.
>
>My vote is for moving ChangeLog maintenance to proper commit message
>maintenance: that is more important for a developer with version control
>access, and again, DVCS use means that this info is available off-line
>to the user/programmer. With CVS, it wasn't.
>
>> Maybe we can try to strike a balance between not keeping the ChangeLog
>> up to date at all and making it difficult to commit *one* changeset
>> that includes both ChangeLog updates _and_ file updates by committing
>> the ChangeLog updates separately?
>
>I don't consider it useful anymore to artificially split relevant change
>info between ChangeLog and commit messages: all relevant version control
>tools (graphical browsers etc) access the commit messages, and those are
>there also offline.
>
>There is no info we want in ChangeLog that should be missing from commit
>messages.
>
>The price Emacs developers pay for following the proposed hair-splitting
>policies now is too high. With CVS, off-line access to the ChangeLog
>was a somewhat valid argument. With DVCS, it isn't.
+1 all over this.
Our commit logs should follow the same structure ChangeLog entries
currently do, and we should not maintain separate ChangeLog files.
There would be zero information loss; also much less confusion, and much
less time wasted discussing how to maintain the same information in two
places.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
0 siblings, 2 replies; 97+ messages in thread
From: Chong Yidong @ 2009-12-31 20:14 UTC (permalink / raw
To: Karl Fogel; +Cc: David Kastrup, emacs-devel
Karl Fogel <kfogel@red-bean.com> writes:
> Our commit logs should follow the same structure ChangeLog entries
> currently do, and we should not maintain separate ChangeLog files.
It's already been decided that we'll continue to maintain ChangeLog
files. This is an awfully marginal issue, so let's not waste any more
time arguing. Just write the ChangeLog entries the way we've all been
doing, and pull them into the commit log (`C-c C-a' if you're using VC).
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 19:44 ` Karl Fogel
@ 2009-12-31 20:16 ` Eli Zaretskii
2009-12-31 20:41 ` Juanma Barranquero
` (2 subsequent siblings)
3 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2009-12-31 20:16 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, lekktu, emacs-devel
> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Thu, 31 Dec 2009 14:44:51 -0500
>
> I've never used 'bzr rebase', and have no competency to evaluate the
> arguments either way here, but... wouldn't something would smell fishy
> if rebase were part of our regular workflow? That somehow seems wrong.
I originally thought this was the case, but I was mistaken; see
Óscar's message just now. It is for a situation that hopefully will
not happen too often for too many.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 20:14 ` Chong Yidong
@ 2009-12-31 20:36 ` Óscar Fuentes
2009-12-31 20:44 ` Juanma Barranquero
1 sibling, 0 replies; 97+ messages in thread
From: Óscar Fuentes @ 2009-12-31 20:36 UTC (permalink / raw
To: emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
>> Our commit logs should follow the same structure ChangeLog entries
>> currently do, and we should not maintain separate ChangeLog files.
>
> It's already been decided that we'll continue to maintain ChangeLog
> files. This is an awfully marginal issue, so let's not waste any more
> time arguing.
It's far from being a marginal issue, it affects the convenience of
Bazaar for most of the work that does not consists on committing to
upstream immediately (i.e. the centralized on-line workflow, CVS-style.)
I agree that discussing it now is worthless, though. After some weeks of
using Bazaar, people will experience the issues by themselves and then
it would be much more easier to reach a consensus.
[snip]
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 18:27 ` Eli Zaretskii
2009-12-31 18:59 ` Óscar Fuentes
@ 2009-12-31 20:39 ` Juanma Barranquero
1 sibling, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 20:39 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
On Thu, Dec 31, 2009 at 19:27, Eli Zaretskii <eliz@gnu.org> wrote:
> So what problem was it in this case, for which rebase is a solution?
> Is it the case of a number of small unrelated changes that somehow
> accumulated in the local branch?
Yes. Not that "somehow accumulate", but that I want to accumulate,
because I don't want to have to branch (and bootstrap) ten times for
ten different small patches that cannot be committed before the
release.
FWIW, I *don't* have currently ten such commits, just one or two; but
I'm not very inclined to branch just to remember to change "(defun
xxx-mode () ...)" to "(define-derived-mode xxx-mode ...)" in a few
weeks/months.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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 13:49 ` Stephen J. Turnbull
3 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 20:41 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, Eli Zaretskii, emacs-devel
On Thu, Dec 31, 2009 at 20:44, Karl Fogel <kfogel@red-bean.com> wrote:
> I've never used 'bzr rebase', and have no competency to evaluate the
> arguments either way here, but... wouldn't something would smell fishy
> if rebase were part of our regular workflow?
Only if you have a priori bias that rebase smells funny.
But anyhow, I don't think anyone is proposing rebase as part of the
regular workflow. I wasn't.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 20:14 ` Chong Yidong
2009-12-31 20:36 ` Óscar Fuentes
@ 2009-12-31 20:44 ` Juanma Barranquero
1 sibling, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2009-12-31 20:44 UTC (permalink / raw
To: Chong Yidong; +Cc: Karl Fogel, David Kastrup, emacs-devel
On Thu, Dec 31, 2009 at 21:14, Chong Yidong <cyd@stupidchicken.com> wrote:
> Just write the ChangeLog entries the way we've all been doing,
...(hopefully) remembering to put that one-line summary at the start...
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
3 siblings, 1 reply; 97+ messages in thread
From: Richard Stallman @ 2010-01-01 2:54 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, lekktu, eliz, emacs-devel
I've never used 'bzr rebase', and have no competency to evaluate the
arguments either way here, but... wouldn't something would smell fishy
if rebase were part of our regular workflow? That somehow seems wrong.
Are you saying that hackers who rebase can get addicted? ;-).
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 14:07 ` Alfred M. Szmidt
2009-12-31 14:16 ` Juanma Barranquero
@ 2010-01-01 2:55 ` Richard Stallman
2010-01-01 4:03 ` Óscar Fuentes
2010-01-01 15:38 ` Alfred M. Szmidt
1 sibling, 2 replies; 97+ messages in thread
From: Richard Stallman @ 2010-01-01 2:55 UTC (permalink / raw
To: ams; +Cc: keramida, lekktu, eliz, schwab, emacs-devel
A major problem with generating the ChangeLog from the commit messages
is that you cannot fix a incorrect entry.
Is there no way to fix an error in a commit message?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 2:55 ` Richard Stallman
@ 2010-01-01 4:03 ` Óscar Fuentes
2010-01-01 8:41 ` Eli Zaretskii
2010-01-01 15:38 ` Alfred M. Szmidt
1 sibling, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2010-01-01 4:03 UTC (permalink / raw
To: emacs-devel
Richard Stallman <rms@gnu.org> writes:
> Is there no way to fix an error in a commit message?
You can undo a commit with `bzr uncommit'. However, this only makes
sense if you are committing to some of your local branches. Once you
send your change upstream, pretending to alter the revision is like
asking for the removal of a message you published on a mailing list,
because the history is replicated everywhere.
Because of this and other more tehcnical reasons, NEVER use `bzr
uncommit' against an upstream branch. You would only cause lots of
misery.
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 4:03 ` Óscar Fuentes
@ 2010-01-01 8:41 ` Eli Zaretskii
2010-01-01 10:04 ` Óscar Fuentes
` (2 more replies)
0 siblings, 3 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 8:41 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 01 Jan 2010 05:03:57 +0100
>
> Richard Stallman <rms@gnu.org> writes:
>
> > Is there no way to fix an error in a commit message?
>
> You can undo a commit with `bzr uncommit'.
But the issue is not to undo the commit, only fix the text of the
commit message. Something similar to "cvs admin -mREV:MESSAGE".
Typos in commit messages still can happen, even with bzr ;-)
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:59 ` Stephen J. Turnbull
2 siblings, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2010-01-01 10:04 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> > Is there no way to fix an error in a commit message?
>>
>> You can undo a commit with `bzr uncommit'.
>
> But the issue is not to undo the commit, only fix the text of the
> commit message. Something similar to "cvs admin -mREV:MESSAGE".
There is no equivalent for `cvs admin -mREV' in bazaar.
Maybe it is not clear from my description that `bzr uncommit' does not
throw away the change: it reverses the state to the point previous to
the commit, so you do
bzr uncommit
bzr commit -m "the right message here"
> Typos in commit messages still can happen, even with bzr ;-)
AFAIK, the commit message is a part of the revision, so if bazaar
allowed to simply edit it, you would be "transmuting" the revision,
(i.e. it would have a different revision-id) and that is absolutely
forbidden in DVCSs. What you can do is to remove some revisions and
replace them with others. Just don't do it on public branches.
You can change anything on the history of your private branch using a
variety of techniques (being `bzr uncommit' the simplest one,) but we
have to admit that changing the message of an arbitrary revision is
something that can't be done due to the nature of DVCSs
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 8:41 ` Eli Zaretskii
2010-01-01 10:04 ` Óscar Fuentes
@ 2010-01-01 12:19 ` Andreas Schwab
2010-01-01 14:33 ` Eli Zaretskii
2010-01-01 14:59 ` Stephen J. Turnbull
2 siblings, 1 reply; 97+ messages in thread
From: Andreas Schwab @ 2010-01-01 12:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> But the issue is not to undo the commit, only fix the text of the
> commit message.
That's fundamentally the same.
> Something similar to "cvs admin -mREV:MESSAGE".
You have to forget the idea that you can modify (published) history.
With a DVCS you can only create history. Once you have published a
commit it is immutable.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 97+ messages in thread
* Workflow to accumulate individual changes?
2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero
` (2 preceding siblings ...)
2009-12-30 22:54 ` Giorgos Keramidas
@ 2010-01-01 12:33 ` Stephen J. Turnbull
2010-01-02 1:56 ` Juanma Barranquero
3 siblings, 1 reply; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-01 12:33 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs developers
Juanma Barranquero writes:
> 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.
I don't understand what you're concerned about (yes, I've seen the
followup which includes the footnote). If you follow the procedure
for creating a shared repository (described in BzrForEmacsDevs, among
other places), then all branches under the shared repository directory
share storage, and creating a branch is very cheap (ie, the cost of
copying the tree, which is small since you can use hardlinks).[1] I
would think this would be fine for anything requiring more than one
commit. In any case, I think it would be worth trying, you might find
it's perfectly satisfactory.
You can make this slightly cheaper by using "checkout --lightweight"
(but the main cost is still creating the tree).
If you have a series of one-commit changes, the cheapest way to do it
would be with rebase. (N.B. I can't help you with "bzr rebase"
itself, I've never used it.) The idea would be to put each commit in
the same branch. You will almost certainly have exactly one conflict
per ChangeLog you touch, but after that your commits will take place
on top of the previous one, and should be fine (at least, I think bzr
is smart enough not to conflict again).
> Once the trunk is open again, what would be the procedure to install
> the changes?
If you follow any of the above, you would just follow the usual
procedure for installing as described in BzrForEmacsDevs.
> Obviously not "bzr merge ../post-23.2", because that would create a
> single [merge] commit.
Yup, see attached script[2]. I don't have a plugin, but I have a
script that you can use to simulate the workflow you propose (if
you're on Windows you'll need to .BATify or use Cygwin). Tested and
works on Gentoo GNU/Linux. Two workflows I tried unsuccessfully are
also documented there for posterity.
Footnotes:
[1] You may need to tune the branch command to use hardlinks instead
of copies.
[2]
# set up a trunk mirror as usual
# test code: uncomment next statement to test
TESTP=t
if test -n "$TESTP"; then
newfile () { echo $1 > $1; bzr add $1; }
addlog () { echo $1 > .tmp0; cat .tmp0 ChangeLog > .tmp1; mv .tmp1 ChangeLog; }
cd /tmp
mkdir shared-repo
cd shared-repo
bzr init-repo
mkdir remote-trunk
cd remote-trunk
bzr init
newfile ChangeLog
newfile foo
bzr commit -m "add foo"
cd ..
bzr checkout remote-trunk trunk
fi
# set up your post 23.2 branch
bzr branch trunk post-23.2
cd post-23.2
# hack ... commit ... hack ... commit ... until trunk open
# more test code
if test -n "$TESTP"; then
newfile bar
addlog 'add bar'
bzr commit -m 'add bar'
newfile baz
addlog 'add baz'
bzr commit -m 'add baz'
# simulate concurrent work
cd ../remote-trunk
newfile quux
addlog 'add quux'
bzr commit -m 'add quux'
fi
# here's the install procedure itself
cd ../trunk
bzr update
# trunk is now up-to-date
cd ../post-23.2
# durn, in testing the update fails, branches have diverged
# bzr update
# durn, in testing the merge --pull succeeds but leaves you with the
# remote changes at the top
bzr merge --pull
# what I hoped for but doesn't actually work (it creates a true merge
# rather than a fast forward)
# cd ../trunk
# bzr pull ../post-23.2
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 2:54 ` Richard Stallman
@ 2010-01-01 12:35 ` Stephen J. Turnbull
0 siblings, 0 replies; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-01 12:35 UTC (permalink / raw
To: rms; +Cc: Karl Fogel, ofv, eliz, emacs-devel, lekktu
Richard Stallman writes:
> I've never used 'bzr rebase', and have no competency to evaluate the
> arguments either way here, but... wouldn't something would smell fishy
> if rebase were part of our regular workflow? That somehow seems wrong.
>
> Are you saying that hackers who rebase can get addicted? ;-).
There's plenty of examples!
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 19:44 ` Karl Fogel
` (2 preceding siblings ...)
2010-01-01 2:54 ` Richard Stallman
@ 2010-01-01 13:49 ` Stephen J. Turnbull
3 siblings, 0 replies; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-01 13:49 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, Juanma Barranquero, Eli Zaretskii, emacs-devel
Karl Fogel writes:
> Juanma Barranquero <lekktu@gmail.com> writes:
> >Well, I can agree with that if you can agree that perhaps rebase
> >*could be* the best fix after all... ;-)
>
> I've never used 'bzr rebase', and have no competency to evaluate the
> arguments either way here, but... wouldn't something would smell fishy
> if rebase were part of our regular workflow? That somehow seems wrong.
No, it's a matter of style. Let me summarize:
1. Everybody agrees that rebasing a branch which is not 100% private
is problematic.
2. Some people like rebasing private branches before pushing them,
basically because it makes the history more linear. (git people
generally do.) Making the history more linear often makes
bisection more effective, because (except for the initial graft)
the patches tend to be smaller and localize the defect better.
3. Some people dislike rebasing private branches, because it makes
the history more linear. (bzr people generally do.) There are
two reasons typically given:
a. Work done concurrently is "misrepresented" as being
sequential. I suspect these people generally have an
intuition of b, but don't express it that way.
b. It's easy to think that all commits have properly tested
because all commits on each (original) branch and the tip have
been tested, but that is false. In fact, all commits between
the graft point and the tip need to be retested. Of course,
"need" is assuming a "test every commit" discipline.
There's a reason that is not typically given, too.
c. In some DVCSes, rebase destroys history. It is in general not
possible to recover the original branch from a rebase given
only the "after" DAG. In bzr a rebase makes recovering the
original branch a task for someone familiar with the
internals. (It may even be impossible in some cases, I don't
know enough about the internals to say.)
If it's not obvious, let me state that I am biased toward the
pro-rebase side. But that's a matter of taste.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-30 23:57 ` Juanma Barranquero
2009-12-31 0:21 ` Óscar Fuentes
2009-12-31 1:04 ` Óscar Fuentes
@ 2010-01-01 13:53 ` Stephen J. Turnbull
2010-01-01 14:38 ` Eli Zaretskii
2 siblings, 1 reply; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-01 13:53 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Óscar Fuentes, emacs-devel
Juanma Barranquero writes:
> bzr push # ugh
> # dates in ChangeLog are wrong, so you need an additional commit to
> fix the ChangeLog entries
>
> so it only really works for fixes that do not need ChangeLog entries.
Why are the dates in the ChangeLog wrong? The commit history is in
"bzr log", the work history is in the ChangeLog. What's the problem
with that? Does Emacs have a policy that ChangeLog dates must
correspond to the commit sequence or some such?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 12:19 ` Andreas Schwab
@ 2010-01-01 14:33 ` Eli Zaretskii
2010-01-01 14:48 ` Andreas Schwab
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 14:33 UTC (permalink / raw
To: Andreas Schwab; +Cc: ofv, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: =?utf-8?Q?=C3=93scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 13:19:14 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > But the issue is not to undo the commit, only fix the text of the
> > commit message.
>
> That's fundamentally the same.
Perhaps in bzr it is, but not in real life.
> > Something similar to "cvs admin -mREV:MESSAGE".
>
> You have to forget the idea that you can modify (published) history.
> With a DVCS you can only create history. Once you have published a
> commit it is immutable.
A commit message is not history, it's a label of that history.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 13:53 ` Stephen J. Turnbull
@ 2010-01-01 14:38 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 14:38 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: ofv, lekktu, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 01 Jan 2010 22:53:20 +0900
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>
> Does Emacs have a policy that ChangeLog dates must correspond to the
> commit sequence or some such?
Yes.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 14:33 ` Eli Zaretskii
@ 2010-01-01 14:48 ` Andreas Schwab
2010-01-01 19:18 ` Karl Fogel
0 siblings, 1 reply; 97+ messages in thread
From: Andreas Schwab @ 2010-01-01 14:48 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> A commit message is not history
It is an integral part of the commit.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 8:41 ` Eli Zaretskii
2010-01-01 10:04 ` Óscar Fuentes
2010-01-01 12:19 ` Andreas Schwab
@ 2010-01-01 14:59 ` Stephen J. Turnbull
2010-01-01 15:30 ` Eli Zaretskii
2 siblings, 1 reply; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-01 14:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
Eli Zaretskii writes:
> > From: Óscar_Fuentes <ofv@wanadoo.es>
> > Date: Fri, 01 Jan 2010 05:03:57 +0100
> >
> > Richard Stallman <rms@gnu.org> writes:
> >
> > > Is there no way to fix an error in a commit message?
> >
> > You can undo a commit with `bzr uncommit'.
>
> But the issue is not to undo the commit, only fix the text of the
> commit message. Something similar to "cvs admin -mREV:MESSAGE".
There's no reason practical or otherwise not to do uncommit, then
commit again, as long as you're on a private branch. git and darcs
provide "git commit --amend" and "darcs amend-commit" which do exactly
what you want, except that they change the identity of the commit (see
below). Eg as a shell function
bzr-amend-last-commit () {
COMMIT_LOG=$1
bzr uncommit
bzr commit -m "$COMMIT_LOG"
}
There are also filter-branch capabilities in both git and bzr (quite
expensive in bzr, though) that would allow you to amend an old commit
log on a private branch.
If I really needed to fix a message in a published git branch I would
use a heavyweight tag named "README-something". I don't think there's
anything similar in bzr, though.
> Typos in commit messages still can happen, even with bzr ;-)
This has been endlessly discussed on at least the Darcs and Bazaar
lists.
The gist is that the commit log is part of the historical record, and
is checksummed, along with the rest of the history data (eg date and
author information). This checksum becomes part of the revision
identifier, and thus if you change any of the data, including the
commit log, you've changed the identity of the revision. As described
elsewhere, that revision identifier is used in various places; it's
not an implemention-internal datum.
I don't think there's any theoretical problem with attaching the log
message externally (at least, external to the checksummed content) as
a comment, somehow. However, from personal experience I can say that
while I still make the same number of typos in log messages as when I
was using CVS, I make far fewer errors of the form of omitting
important information because I commit much more frequently and my log
messages are both shorter (per message) and more detailed. So I
suspect you'd get resistence to such a suggestion, both on principle
("The log message is part of history") and practically ("there's no
real benefit, it would take work to do, and it slightly weakens our
internal consistency guarantee").
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 14:59 ` Stephen J. Turnbull
@ 2010-01-01 15:30 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 15:30 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: ofv, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>,
> emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 23:59:20 +0900
>
> So I suspect you'd get resistence to such a suggestion, both on
> principle ("The log message is part of history") and practically
> ("there's no real benefit, it would take work to do, and it slightly
> weakens our internal consistency guarantee").
Forget it. It's easier to set up flyspell for the log buffers.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 2:55 ` Richard Stallman
2010-01-01 4:03 ` Óscar Fuentes
@ 2010-01-01 15:38 ` Alfred M. Szmidt
1 sibling, 0 replies; 97+ messages in thread
From: Alfred M. Szmidt @ 2010-01-01 15:38 UTC (permalink / raw
To: rms; +Cc: keramida, lekktu, eliz, schwab, emacs-devel
A major problem with generating the ChangeLog from the commit messages
is that you cannot fix a incorrect entry.
Is there no way to fix an error in a commit message?
That is the case, once one publishes a revision there is no way of
amending the commit message.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2009-12-31 14:16 ` Juanma Barranquero
@ 2010-01-01 15:38 ` Alfred M. Szmidt
2010-01-01 17:53 ` David Kastrup
0 siblings, 1 reply; 97+ messages in thread
From: Alfred M. Szmidt @ 2010-01-01 15:38 UTC (permalink / raw
To: Juanma Barranquero; +Cc: keramida, eliz, schwab, emacs-devel
Still, that seems to me a lesser problem that having to check two
places to get all relevant info. And, if you look deep at our
ChangeLogs, after years and years of use I'm sure you wouldn't take
more than half an hour to find some mistake (I'm not talking about
typos, but missing, wrong or duplicate entries, etc.).
That may be true, but it is not a argument to make it impossible to
fix incorrect entries. Having proper entries is good for developers,
and for copyright reasons.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 15:38 ` Alfred M. Szmidt
@ 2010-01-01 17:53 ` David Kastrup
0 siblings, 0 replies; 97+ messages in thread
From: David Kastrup @ 2010-01-01 17:53 UTC (permalink / raw
To: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Still, that seems to me a lesser problem that having to check two
> places to get all relevant info. And, if you look deep at our
> ChangeLogs, after years and years of use I'm sure you wouldn't take
> more than half an hour to find some mistake (I'm not talking about
> typos, but missing, wrong or duplicate entries, etc.).
>
> That may be true, but it is not a argument to make it impossible to
> fix incorrect entries. Having proper entries is good for developers,
> and for copyright reasons.
I don't see what "copyright reasons" would make it a good idea to let a
commit+message done by A be silently (or non-silently) be changed by B
at a later date.
--
David Kastrup
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 14:48 ` Andreas Schwab
@ 2010-01-01 19:18 ` Karl Fogel
2010-01-01 19:56 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 97+ messages in thread
From: Karl Fogel @ 2010-01-01 19:18 UTC (permalink / raw
To: Andreas Schwab; +Cc: ofv, Eli Zaretskii, emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>> A commit message is not history
>
>It is an integral part of the commit.
This is an old debate in the DVCS world. The issue is that changes are
distributed and there is no "master copy" of a given change; instead,
there are many copies of the same change, and you can tell they're the
same because they all have the same unique id (and same contents).
In CVS, the master copy is always in the repository and there is exactly
one repository. So if you want to read log messages, you do 'cvs log'
and it contacts the repository (or, in Emacs's case, 'cvs update' gets
updates to the ChangeLog files, but that also contacts the repository).
In Bzr, the savannah trunk branch is sort of the equivalent CVS's "the
repository"... but the changes in that branch are replicated among
hundreds or thousands of developers' local branches. If you tweak a
commit message on the savannah branch, bzr has no mechanism for
conveying that tweak to the other branches, because the commit message
is considered part of the change, just like the diff. Tweak the commit
message and you've tweaked the change -- it's no longer the same change.
There are other ways the system could work. IIUC, in git the commit
message is *not* part of the change's identity, it's just attached to
the change, so you can edit the message later. But I don't know if git
has a way of propagating those edits to other clones; nor do I know what
git would do if two different clones tweak a commit message for the
"same" change in two different ways and then one of them has to receive
the other's edits. Is there conflict resolution on "out-of-band" data,
and if so, how would it work?
Perhaps the difficulty of that question is why bzr doesn't support this.
In any case, IMHO it is a minor feature regression that we can no longer
tweak log messages after the fact, but it's not a huge problem.
-Karl
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 19:18 ` Karl Fogel
@ 2010-01-01 19:56 ` Eli Zaretskii
2010-01-01 20:09 ` Chong Yidong
` (2 more replies)
2010-01-01 20:07 ` Teemu Likonen
2010-01-02 4:37 ` Stephen J. Turnbull
2 siblings, 3 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 19:56 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 14:18:00 -0500
>
> If you tweak a commit message on the savannah branch, bzr has no
> mechanism for conveying that tweak to the other branches
Well, that's just it: bzr _should_ have such a mechanism. I really
don't care if modifying a commit message would count as a new revision
of the tree, all I care is that "bzr log" and friends show the
modified commit message by default (if there would be a way to see the
original one before the fix, that's okay too).
> because the commit message
> is considered part of the change, just like the diff. Tweak the commit
> message and you've tweaked the change -- it's no longer the same change.
There's no requirement to pretend the tree is the same after modifying
the commit message. The requirement is that "bzr log" shows it with
the commit, that's all.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 19:18 ` Karl Fogel
2010-01-01 19:56 ` Eli Zaretskii
@ 2010-01-01 20:07 ` Teemu Likonen
2010-01-01 20:12 ` Karl Fogel
2010-01-02 4:37 ` Stephen J. Turnbull
2 siblings, 1 reply; 97+ messages in thread
From: Teemu Likonen @ 2010-01-01 20:07 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel
On 2010-01-01 14:18 (-0500), Karl Fogel wrote:
> IIUC, in git the commit message is *not* part of the change's
> identity, it's just attached to the change, so you can edit the
> message later.
That's wrong--or your "change's identity" means something I don't
understand. In Git commit's author, committer, date, parent commits'
SHA1s, referenced tree object's SHA1 and commit message together make
the content of a commit object. From this content is calculated the SHA1
of that commit object. If you change any of these the SHA1 of the commit
object will be different and hence the whole commit object will be
different (i.e. its identity is different).
So no, it's not possible to change commit message (or any information
the commit object contains) without making it a different commit.
There is a related feature, though. New Git versions have "git notes"
command which allows user to add additional notes to commits. Such extra
notes can be added and removed freely and "git log" prints them after
the commit message. Notes can be sent between repositories but currently
it doesn't happen automatically with usual pull/push commands.
http://www.kernel.org/pub/software/scm/git/docs/git-notes.html
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:25 ` Óscar Fuentes
2 siblings, 1 reply; 97+ messages in thread
From: Chong Yidong @ 2010-01-01 20:09 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Karl Fogel, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> If you tweak a commit message on the savannah branch, bzr has no
>> mechanism for conveying that tweak to the other branches
>
> Well, that's just it: bzr _should_ have such a mechanism. I really
> don't care if modifying a commit message would count as a new revision
> of the tree, all I care is that "bzr log" and friends show the
> modified commit message by default (if there would be a way to see the
> original one before the fix, that's okay too).
I think the problem is that this involves tracking changes to changes.
What if you want to change the change to the change?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 20:07 ` Teemu Likonen
@ 2010-01-01 20:12 ` Karl Fogel
2010-01-01 21:08 ` Teemu Likonen
0 siblings, 1 reply; 97+ messages in thread
From: Karl Fogel @ 2010-01-01 20:12 UTC (permalink / raw
To: Teemu Likonen; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel
Teemu Likonen <tlikonen@iki.fi> writes:
>On 2010-01-01 14:18 (-0500), Karl Fogel wrote:
>> IIUC, in git the commit message is *not* part of the change's
>> identity, it's just attached to the change, so you can edit the
>> message later.
>
>That's wrong--or your "change's identity" means something I don't
>understand. In Git commit's author, committer, date, parent commits'
>SHA1s, referenced tree object's SHA1 and commit message together make
>the content of a commit object. From this content is calculated the SHA1
>of that commit object. If you change any of these the SHA1 of the commit
>object will be different and hence the whole commit object will be
>different (i.e. its identity is different).
Someone -- whom I thought would know -- specifically told me that the
commit message is *not* part of the SHA1 of the commit object. I double
checked, because this was surprising to me, and they confirmed.
But either they were wrong, or I misunderstood, or possibly both. In
any case, I'm sorry for spreading misinformation.
>There is a related feature, though. New Git versions have "git notes"
>command which allows user to add additional notes to commits. Such extra
>notes can be added and removed freely and "git log" prints them after
>the commit message. Notes can be sent between repositories but currently
>it doesn't happen automatically with usual pull/push commands.
>
>http://www.kernel.org/pub/software/scm/git/docs/git-notes.html
Maybe this is what the person thought I was talking about.
-K
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 19:56 ` Eli Zaretskii
2010-01-01 20:09 ` Chong Yidong
@ 2010-01-01 20:13 ` Karl Fogel
2010-01-01 21:35 ` Eli Zaretskii
2010-01-01 21:25 ` Óscar Fuentes
2 siblings, 1 reply; 97+ messages in thread
From: Karl Fogel @ 2010-01-01 20:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org
>> Date: Fri, 01 Jan 2010 14:18:00 -0500
>>
>> If you tweak a commit message on the savannah branch, bzr has no
>> mechanism for conveying that tweak to the other branches
>
>Well, that's just it: bzr _should_ have such a mechanism. I really
>don't care if modifying a commit message would count as a new revision
>of the tree, all I care is that "bzr log" and friends show the
>modified commit message by default (if there would be a way to see the
>original one before the fix, that's okay too).
I agree it's a bug. Having established that... the most productive
place to discuss Bazaar bugs is probably the Bazaar list.
-K
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 20:12 ` Karl Fogel
@ 2010-01-01 21:08 ` Teemu Likonen
2010-01-02 5:00 ` Stephen J. Turnbull
0 siblings, 1 reply; 97+ messages in thread
From: Teemu Likonen @ 2010-01-01 21:08 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel
On 2010-01-01 15:12 (-0500), Karl Fogel wrote:
> Someone -- whom I thought would know -- specifically told me that the
> commit message is *not* part of the SHA1 of the commit object. I
> double checked, because this was surprising to me, and they confirmed.
>
> But either they were wrong, or I misunderstood, or possibly both. In
> any case, I'm sorry for spreading misinformation.
No problem. I'll still repeat that it's indeed misinformation. Here's a
raw content of a certain commit object in Emacs Git repository (the
four-space indent is by me):
$ git cat-file commit 9a339f5
tree ef4fd5bd3689b5c17a3eb6df705564a5d4fed602
parent 031c7e409992e98fefc98c3e8a6be981a00c55a9
author Chong Yidong <cyd@stupidchicken.com> 1261901472 +0000
committer Chong Yidong <cyd@stupidchicken.com> 1261901472 +0000
* minibuf.c (Fall_completions): Minor optimization.
We can see the commit message in the end. "git log" prints it like this:
$ git log -1 9a339f5
commit 9a339f5040b089f97a4b5c86eefa3942b2e5eda4
Author: Chong Yidong <cyd@stupidchicken.com>
Date: 2009-12-27 08:11:12 +0000
* minibuf.c (Fall_completions): Minor optimization.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 19:56 ` Eli Zaretskii
2010-01-01 20:09 ` Chong Yidong
2010-01-01 20:13 ` Karl Fogel
@ 2010-01-01 21:25 ` Óscar Fuentes
2010-01-01 21:34 ` Eli Zaretskii
2 siblings, 1 reply; 97+ messages in thread
From: Óscar Fuentes @ 2010-01-01 21:25 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> If you tweak a commit message on the savannah branch, bzr has no
>> mechanism for conveying that tweak to the other branches
>
> Well, that's just it: bzr _should_ have such a mechanism. I really
> don't care if modifying a commit message would count as a new revision
> of the tree, all I care is that "bzr log" and friends show the
> modified commit message by default (if there would be a way to see the
> original one before the fix, that's okay too).
By replacing a revision with another revision, you are effectively
breaking the mirror branches on all sites that updated/pulled before the
"fix" (you make them diverge.) And that's the easier part. You will
cause lots of problems, really.
A mechanism that notices that certain revision replaces a previous one
and propagates the fact when two branches communicate, not only would be
very complex, but quite questionable from the ethical POV, as it could
be used to modify or destroy VC history by a malicious individual.
As for the commit message and other metadata such as the committer name
being part of the hashed data, it is considered a fundamental
requirement for keeping history integrity.
[snip]
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 21:25 ` Óscar Fuentes
@ 2010-01-01 21:34 ` Eli Zaretskii
2010-01-01 22:58 ` Andreas Schwab
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 21:34 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 01 Jan 2010 22:25:20 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> If you tweak a commit message on the savannah branch, bzr has no
> >> mechanism for conveying that tweak to the other branches
> >
> > Well, that's just it: bzr _should_ have such a mechanism. I really
> > don't care if modifying a commit message would count as a new revision
> > of the tree, all I care is that "bzr log" and friends show the
> > modified commit message by default (if there would be a way to see the
> > original one before the fix, that's okay too).
>
> By replacing a revision with another revision, you are effectively
> breaking the mirror branches on all sites that updated/pulled before the
> "fix" (you make them diverge.)
Who said anything about replacing a revision? I was talking about
_adding_ a revision, if needed. It just needs to be added in a
special way, such that nothing changes except the addition of a
modified commit message, and "bzr log" showing that modified message
instead of the original one.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 20:09 ` Chong Yidong
@ 2010-01-01 21:34 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 21:34 UTC (permalink / raw
To: Chong Yidong; +Cc: kfogel, emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 15:09:06 -0500
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> If you tweak a commit message on the savannah branch, bzr has no
> >> mechanism for conveying that tweak to the other branches
> >
> > Well, that's just it: bzr _should_ have such a mechanism. I really
> > don't care if modifying a commit message would count as a new revision
> > of the tree, all I care is that "bzr log" and friends show the
> > modified commit message by default (if there would be a way to see the
> > original one before the fix, that's okay too).
>
> I think the problem is that this involves tracking changes to changes.
> What if you want to change the change to the change?
Just add another revision. It's the same as with versioned files,
really.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 20:13 ` Karl Fogel
@ 2010-01-01 21:35 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-01 21:35 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
> From: Karl Fogel <kfogel@red-bean.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 15:13:00 -0500
>
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Karl Fogel <kfogel@red-bean.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org
> >> Date: Fri, 01 Jan 2010 14:18:00 -0500
> >>
> >> If you tweak a commit message on the savannah branch, bzr has no
> >> mechanism for conveying that tweak to the other branches
> >
> >Well, that's just it: bzr _should_ have such a mechanism. I really
> >don't care if modifying a commit message would count as a new revision
> >of the tree, all I care is that "bzr log" and friends show the
> >modified commit message by default (if there would be a way to see the
> >original one before the fix, that's okay too).
>
> I agree it's a bug. Having established that... the most productive
> place to discuss Bazaar bugs is probably the Bazaar list.
Done.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 21:34 ` Eli Zaretskii
@ 2010-01-01 22:58 ` Andreas Schwab
0 siblings, 0 replies; 97+ messages in thread
From: Andreas Schwab @ 2010-01-01 22:58 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Who said anything about replacing a revision? I was talking about
> _adding_ a revision, if needed. It just needs to be added in a
> special way, such that nothing changes except the addition of a
> modified commit message, and "bzr log" showing that modified message
> instead of the original one.
There needs to be a reference to this added information, otherwise
nobody will see it.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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 3:46 ` Stephen J. Turnbull
0 siblings, 2 replies; 97+ messages in thread
From: Juanma Barranquero @ 2010-01-02 1:56 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Emacs developers
On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> I don't understand what you're concerned about (yes, I've seen the
> followup which includes the footnote).
Well, if you read the note, you know what am I concerned about: not
the time for checking out the files, but the time to get the branch in
a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
while "make bootstrap" is ~20min. The only fix for that is creating a
script to copy .o, .elc and other generated files from another branch.
Quite a fuss just to commit (and store for the future) a one-liner;
that's why I think of having a branch for these micro-issues. (Well,
colocated branches à la git would be wonderful for this case...)
> and creating a branch is very cheap (ie, the cost of
> copying the tree, which is small since you can use hardlinks).[1]
As I've said above, it's not the time to create the branch that
worries me; that said, Bazaar does not support hardlinks on Windows,
AFAIK.
> I would think this would be fine for anything requiring more than one
> commit. In any case, I think it would be worth trying, you might find
> it's perfectly satisfactory.
For more serious changes yes, absolutely.
> If you have a series of one-commit changes, the cheapest way to do it
> would be with rebase.
That seems to be the consensus, yes.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 1:56 ` Juanma Barranquero
@ 2010-01-02 2:28 ` Óscar Fuentes
2010-01-02 2:50 ` Juanma Barranquero
` (2 more replies)
2010-01-02 3:46 ` Stephen J. Turnbull
1 sibling, 3 replies; 97+ messages in thread
From: Óscar Fuentes @ 2010-01-02 2:28 UTC (permalink / raw
To: emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
>> I don't understand what you're concerned about (yes, I've seen the
>> followup which includes the footnote).
>
> Well, if you read the note, you know what am I concerned about: not
> the time for checking out the files, but the time to get the branch in
> a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
> while "make bootstrap" is ~20min. The only fix for that is creating a
> script to copy .o, .elc and other generated files from another branch.
> Quite a fuss just to commit (and store for the future) a one-liner;
> that's why I think of having a branch for these micro-issues. (Well,
> colocated branches à la git would be wonderful for this case...)
https://launchpad.net/bzr-loom
It is underdocumented, but it works AFAIK. You can search the internet
for experiences with it.
OTOH, some people emulate colocated branches with `bzr switch'. The idea
is that you have a checkout for hacking that you bind to wathever branch
you chose to work on. For example, lets suppose that you created your
working checkout with:
bzr co trunk my-playground # you need to do this only once
from now on, when you need a small feature, you create a branch for it:
bzr branch --no-tree trunk fix-foo
this is a very fast and inexpensive operation on a shared repository, as
it doesn't even require to create the working tree.
Now, if you want to work on `fix-foo', from `my-playground' you do
bzr switch ../fix-foo
you do something and, eventually
bzr commit -m "done!"
this will update `fix-foo'. Later, you can proced to merge the changes
from `fix-foo' into `trunk' as usual (taking care of the ChangeLog
issue.)
If now you wish to work on a new micro-feature:
cd .. # from `my-playground'
bzr branch --no-tree fix-bar
cd my-playground
bzr status # Test that you don't have pending changes!
bzr switch ../fix-bar
Note that, within a shared repository, you can organize your branches as
you wish, so it is advisable to make a directory `delayed-changes' and
create your mini-feature branches there.
[snip]
--
Óscar
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:17 ` Juanma Barranquero
2 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2010-01-02 2:50 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
On Sat, Jan 2, 2010 at 03:28, Óscar Fuentes <ofv@wanadoo.es> wrote:
> https://launchpad.net/bzr-loom
>
> It is underdocumented, but it works AFAIK. You can search the internet
> for experiences with it.
Yes, I know about loom, though I've not used it. And YES, it is
underdocumented :-)
AFAICS, looms are similar to colocated branches, but threads are
sorted, i.e., they have an order dependency.
> OTOH, some people emulate colocated branches with `bzr switch'. The idea
> is that you have a checkout for hacking that you bind to wathever branch
> you chose to work on. For example, lets suppose that you created your
> working checkout with:
And, in this case, my-playground would be usually in a runnable state,
and "bzr switch ../fix-foo" would only touch the updated files,
minimizing recompilation. Right? Neat idea, I'm gonna give it a try.
Thanks!
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 1:56 ` Juanma Barranquero
2010-01-02 2:28 ` Óscar Fuentes
@ 2010-01-02 3:46 ` Stephen J. Turnbull
2010-01-02 9:10 ` Eli Zaretskii
2010-01-02 13:39 ` Juanma Barranquero
1 sibling, 2 replies; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-02 3:46 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs developers
Juanma Barranquero writes:
> Well, if you read the note, you know what am I concerned about: not
> the time for checking out the files, but the time to get the branch in
> a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
> while "make bootstrap" is ~20min.
Ah, I skipped over that.
The way that is often recommended to handle that is to have a test
tree, which is setup as a checkout. So
bzr branch trunk build-test
cd build-test
make bootstrap
make test # if you like, but should be OK :-)
for i = 1 2 3; do
cd ..
bzr branch trunk fix$i
cd fix$i
# hack
bzr commit -m "fix$i"
cd ../build-test
bzr checkout ../fix$i
make # Look Ma, no 'bootstrap'!
make test
done
YMMV, and caveat hacer: I haven't used this workflow personally, nor
have I tested that my command syntax is correct.
> (Well, colocated branches à la git would be wonderful for this
> case...)
Maybe someday, but AFAICS the main candidates for developing such
(Aaron Bentley and Robert Collins) are putting their efforts into
quilt-cum-VCS efforts ("pipelines" and "looms", respectively).
Somebody like you who has a fair amount of DVCS knowledge already (I
don't know how much that is exactly but I'm pretty sure from your
comments that it is sufficient for this) should look at pipelines
(similar to Mercurial queues, and maybe Stacked Git) and looms.
Pipelines really do have a sequential nature to them, which might or
might not get in the way, and AFAIK they don't yet have an mq-like
guard mechanism. Looms are an original idea of Robert's and some
folks I really respect love them until the fur rubs off. In
particular, they can sort of be abused in a "guard"-like fashion, I
think.
But it will require experimentation; neither pipelines nor looms are
documented up to Bazaar's usual standards. (I agree with Eli about
those standards, by the way; that's why I think experimenting with
these requires "sufficient DVCS background".)
> > If you have a series of one-commit changes, the cheapest way to do it
> > would be with rebase.
>
> That seems to be the consensus, yes.
The methods suggested above might be useful too. For one-off patches,
I use mq all the time because Mercurial's support for colocated
branches "should be indented 6 feet downward", at least from my
relatively git-centric viewpoint. But I also use guards extensively
because I often submit even one-offs for review, so it's not always
the case that writing order is push order. I don't know offhand how
to emulate guards in bzr.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 19:18 ` Karl Fogel
2010-01-01 19:56 ` Eli Zaretskii
2010-01-01 20:07 ` Teemu Likonen
@ 2010-01-02 4:37 ` Stephen J. Turnbull
2 siblings, 0 replies; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-02 4:37 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel
Karl Fogel writes:
> There are other ways the system could work. IIUC, in git the commit
> message is *not* part of the change's identity,
No, in git the commit message is indeed part of the changes's
identity. A commit is a strictly defined structure (that happens to
be UTF-8 text with a final, free-form "comment" field), and the whole
thing is hashed to get the SHA1 identifying the commit.
What git has (and Mercurial, though implemented very differently) is
tag *objects*. The tag object can contain arbitrary content (eg, a
signature), but here it could be used in some conventional way (eg, by
naming it "<sha1>-log-<log-rev-no>" to record an edited message for
commit <sha1>.
> But I don't know if git has a way of propagating those edits to
> other clones;
git commit --amend creates a new commit, propagated in the usual way
for commits. git tag -a creates an annotated tag, propagated in the
usual way for tags.
> In any case, IMHO it is a minor feature regression that we can no longer
> tweak log messages after the fact, but it's not a huge problem.
The problem is that in a DVCS there is no reasonable way to propagate
those changes, and it becomes an issue of what the "official" message
for that commit is. Eg, suppose you tweak. Now different "official"
messages are going to propagate -- some people already have that
commit, and will *not* refetch it because the identity (SHA1) hasn't
changed. Others will update or clone, and get it.
In other words, in git the way to notify other clients that you've
changed the commit message is to change the commit ID. This is true
of all of the DVCSes I've used.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 21:08 ` Teemu Likonen
@ 2010-01-02 5:00 ` Stephen J. Turnbull
2010-01-02 5:12 ` Karl Fogel
0 siblings, 1 reply; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-02 5:00 UTC (permalink / raw
To: Teemu Likonen; +Cc: Karl Fogel, ofv, Eli Zaretskii, Andreas Schwab, emacs-devel
Teemu Likonen writes:
> No problem. I'll still repeat that it's indeed misinformation. Here's a
> raw content of a certain commit object in Emacs Git repository (the
> four-space indent is by me):
cat'ing the object doesn't prove anything. The header content is
easily separable from the commit message, and in theory you could
generate the SHA1 based on the header only. (I can't imagine Linus
doing such a thing, but it would immediately occur to most Emacs
hackers.)
Here's an experimental proof:
# Verify identity.
$ git rev-parse HEAD
f008c025d04f4bcec79f2bb463589461d95a3154
$ git cat-file commit HEAD | git hash-object --stdin -t commit
f008c025d04f4bcec79f2bb463589461d95a3154
# Verify difference -- I happen to know that the word "Update" occurs
# uniquely in the comment portion of this commit.
$ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \
| git hash-object --stdin -t commit
ff2c9790c738d10205086a12ce394069ceccbb83
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 5:00 ` Stephen J. Turnbull
@ 2010-01-02 5:12 ` Karl Fogel
2010-01-02 5:24 ` Miles Bader
0 siblings, 1 reply; 97+ messages in thread
From: Karl Fogel @ 2010-01-02 5:12 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: ofv, Eli Zaretskii, Teemu Likonen, Andreas Schwab, emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>Teemu Likonen writes:
> > No problem. I'll still repeat that it's indeed misinformation. Here's a
> > raw content of a certain commit object in Emacs Git repository (the
> > four-space indent is by me):
>
>cat'ing the object doesn't prove anything. The header content is
>easily separable from the commit message, and in theory you could
>generate the SHA1 based on the header only. (I can't imagine Linus
>doing such a thing, but it would immediately occur to most Emacs
>hackers.)
Heh. I followed up in private mail to Teemu saying the same thing.
>Here's an experimental proof:
>
># Verify identity.
>$ git rev-parse HEAD
>f008c025d04f4bcec79f2bb463589461d95a3154
>$ git cat-file commit HEAD | git hash-object --stdin -t commit
>f008c025d04f4bcec79f2bb463589461d95a3154
>
># Verify difference -- I happen to know that the word "Update" occurs
># uniquely in the comment portion of this commit.
>$ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \
> | git hash-object --stdin -t commit
>ff2c9790c738d10205086a12ce394069ceccbb83
Now *that's* the proof we needed. Thanks.
It would be very winning if some DVCS would
a) Allow tweaking commit messages
b) Version those tweaks
c) Propagate those tweaks to other branches whenever the other branch
receives data from the tweaked branch
d) Have a conflict resolution mechanism for when different tweaks collide
This is a tall order, however. I'm not surprised no DVCS (AFAIK) does it.
-K
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 5:12 ` Karl Fogel
@ 2010-01-02 5:24 ` Miles Bader
2010-01-02 11:43 ` Juanma Barranquero
0 siblings, 1 reply; 97+ messages in thread
From: Miles Bader @ 2010-01-02 5:24 UTC (permalink / raw
To: Karl Fogel
Cc: ofv, emacs-devel, Andreas Schwab, Stephen J. Turnbull,
Teemu Likonen, Eli Zaretskii
Karl Fogel <kfogel@red-bean.com> writes:
> This is a tall order, however. I'm not surprised no DVCS (AFAIK) does it.
Yeah, a complex infrastructure just to fix typos in commit messages
seems a bit over the top.
-Miles
--
Bore, n. A person who talks when you wish him to listen.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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 13:39 ` Juanma Barranquero
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-02 9:10 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: lekktu, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sat, 02 Jan 2010 12:46:30 +0900
> Cc: Emacs developers <emacs-devel@gnu.org>
>
> bzr branch trunk build-test
> cd build-test
> make bootstrap
> make test # if you like, but should be OK :-)
> for i = 1 2 3; do
> cd ..
> bzr branch trunk fix$i
> cd fix$i
> # hack
> bzr commit -m "fix$i"
> cd ../build-test
> bzr checkout ../fix$i
> make # Look Ma, no 'bootstrap'!
> make test
> done
What is the semantics of "bzr checkout ../fix$i" in this case? What
does it do, exactly?
Bazaar docs are not very clear on that, to say the least:
Purpose: Create a new checkout of an existing branch.
But fix$i is already an existing branch, and one with local changes,
so this ``create'' seems not quite the right word here.
Usage: bzr checkout [BRANCH_LOCATION] [TO_LOCATION]
Description: If BRANCH_LOCATION is omitted, checkout will reconstitute
a working tree for the branch found in ‘.’.
[...]
If the TO_LOCATION is omitted, the last component of the
BRANCH_LOCATION will be used. In other words, “checkout
../foo/bar” will attempt to create ./bar. If the
BRANCH_LOCATION has no / or path separator embedded,
the TO_LOCATION is derived from the BRANCH_LOCATION
by stripping a leading scheme or drive identifier, if
any. For example, “checkout lp:foo-bar” will attempt
to create ./foo-bar.
Again, ``create ./bar'' sounds incorrect in the context of your
suggestion. ``Reconstitute a working tree'', OTOH, sounds too obscure
to help.
So what does this "checkout" do in this case?
(Btw, note the tricky convention regarding slashes, not for the faint
of heart IMO.)
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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
2 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-02 9:11 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sat, 02 Jan 2010 03:28:31 +0100
>
> If now you wish to work on a new micro-feature:
>
> cd .. # from `my-playground'
> bzr branch --no-tree fix-bar
> cd my-playground
> bzr status # Test that you don't have pending changes!
> bzr switch ../fix-bar
Why is "bzr status" above important? what happens if I do have pending
changes before switching?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 5:24 ` Miles Bader
@ 2010-01-02 11:43 ` Juanma Barranquero
2010-01-02 12:09 ` Miles Bader
0 siblings, 1 reply; 97+ messages in thread
From: Juanma Barranquero @ 2010-01-02 11:43 UTC (permalink / raw
To: Miles Bader
Cc: ofv, emacs-devel, Karl Fogel, Andreas Schwab, Stephen J. Turnbull,
Teemu Likonen, Eli Zaretskii
On Sat, Jan 2, 2010 at 06:24, Miles Bader <miles@gnu.org> wrote:
> Yeah, a complex infrastructure just to fix typos in commit messages
> seems a bit over the top.
Though I agree with you, let's not misrepresent the issue; changing
commit messages is not just about typos, but also wrong or misleading
information.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 11:43 ` Juanma Barranquero
@ 2010-01-02 12:09 ` Miles Bader
2010-01-02 19:22 ` Karl Fogel
0 siblings, 1 reply; 97+ messages in thread
From: Miles Bader @ 2010-01-02 12:09 UTC (permalink / raw
To: Juanma Barranquero
Cc: ofv, emacs-devel, Karl Fogel, Andreas Schwab, Stephen J. Turnbull,
Teemu Likonen, Eli Zaretskii
Juanma Barranquero <lekktu@gmail.com> writes:
>> Yeah, a complex infrastructure just to fix typos in commit messages
>> seems a bit over the top.
>
> Though I agree with you, let's not misrepresent the issue; changing
> commit messages is not just about typos, but also wrong or misleading
> information.
Nonetheless, IME, it's _extremely_ rare for it to represent a serious
issue, and nowhere near enough of a problem to be worth the cost of such
a mechanism.
-Miles
--
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
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:17 ` Juanma Barranquero
2 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2010-01-02 13:17 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
On Sat, Jan 2, 2010 at 03:28, Óscar Fuentes <ofv@wanadoo.es> wrote:
> OTOH, some people emulate colocated branches with `bzr switch'.
It works like a charm.
> Note that, within a shared repository, you can organize your branches as
> you wish, so it is advisable to make a directory `delayed-changes' and
> create your mini-feature branches there.
The fact that the branch for "bzr switch BRANCH" can be relative to
the parent dir makes this even easier.
It'd be worth documenting this somewhere to give it this higher
visibility, IMO, than a single paragraph in bzr help checkouts:
Another possible use for a checkout is to use it with a treeless repository
containing your branches, where you maintain only one working tree by
switching the master branch that the checkout points to when you want to
work on a different branch.
BTW, what's the use of "branch --switch"? Something like this:
# trunk/ (main mirror)
# my-playground/ ("working" checkout)
# delayed-changes/branch1, branch2, etc. (treeless branches)
# from my-playground
bzr branch --no-tree --switch ../trunk ../delayed-changes/branchN
so you create a new branch and switch to it in a single op? Sweet,
worth of an alias.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 9:11 ` Eli Zaretskii
@ 2010-01-02 13:20 ` Juanma Barranquero
0 siblings, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2010-01-02 13:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel
On Sat, Jan 2, 2010 at 10:11, Eli Zaretskii <eliz@gnu.org> wrote:
> Why is "bzr status" above important?
It shouldn't be needed, though it seems sensible to do it before
switching your tree...
> what happens if I do have pending
> changes before switching?
They get merged:
[...] the working tree is updated and uncommitted changes
are merged. The user can commit or revert these as they desire.
Pending merges need to be committed or reverted before using switch.
Conflicts are marked as expected.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 3:46 ` Stephen J. Turnbull
2010-01-02 9:10 ` Eli Zaretskii
@ 2010-01-02 13:39 ` Juanma Barranquero
1 sibling, 0 replies; 97+ messages in thread
From: Juanma Barranquero @ 2010-01-02 13:39 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Emacs developers
On Sat, Jan 2, 2010 at 04:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Somebody like you who has a fair amount of DVCS knowledge already (I
> don't know how much that is exactly
Not much, though a lot more than a couple months ago :-)
> should look at pipelines
> (similar to Mercurial queues, and maybe Stacked Git) and looms.
Yes, I have both installed. But when you say
> neither pipelines nor looms are
> documented up to Bazaar's usual standards.
that's an understatement :-) After reading "bzr help loom", the first
question is, well, what's exactly a loom and what it is good for?
There are too many assumptions and too few clear statements of purpose
and use cases. pipeline is slightly better documented.
Juanma
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 9:10 ` Eli Zaretskii
@ 2010-01-02 15:30 ` Stephen J. Turnbull
2010-01-02 17:05 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-02 15:30 UTC (permalink / raw
To: Eli Zaretskii; +Cc: lekktu, emacs-devel
Eli Zaretskii writes:
> > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> > Date: Sat, 02 Jan 2010 12:46:30 +0900
> > Cc: Emacs developers <emacs-devel@gnu.org>
Urk, I'd been working in Mercurial and mixed semantics. (I really,
really hate the way all the DVCSes insist on using each others'
command names and features but with different semantics attached to
the same name.) I think Óscar got it right, though. After testing,
this should be revised as below
> > bzr branch trunk build-test
A lightweight checkout is often recommended here instead of branch:
bzr checkout --lightweight trunk build-test
It's more efficient.
> > cd build-test
> > make bootstrap
> > make test # if you like, but should be OK :-)
> > for i = 1 2 3; do
> > cd ..
> > bzr branch trunk fix$i
> > cd fix$i
> > # hack
> > bzr commit -m "fix$i"
> > cd ../build-test
Oops, this is where I went WRONG:
> > bzr checkout ../fix$i
RIGHT:
bzr switch ../fix$i
> > make # Look Ma, no 'bootstrap'!
> > make test
> > done
>
> What is the semantics of "bzr checkout ../fix$i" in this case? What
> does it do, exactly?
(Checkout in fact will error here, or perhaps produce a fix$i subtree.
Not what you want.)
"bzr switch fix$i" says
Purpose: Set the branch of a checkout and update.
Usage: bzr switch TO_LOCATION
Options:
--force Switch even if local commits will be lost.
-v, --verbose Display more information.
-q, --quiet Only display errors and warnings.
--usage Show usage message and options.
-b, --create-branch Create the target branch from this one
before switching to it.
-h, --help Show help message.
Description:
For lightweight checkouts, this changes the branch being
referenced. For heavyweight checkouts, this checks that there
are no local commits versus the current bound branch, then it
makes the local branch a mirror of the new location and binds to
it.
# In informal terms, the above says "this workspace now refers to the
# new branch for VCS information."
In both cases, the working tree is updated and uncommitted
changes are merged. The user can commit or revert these as they
desire.
# The update happens automatically and immediately upon "bzr switch".
# In the workflow described above, the "uncommitted changes" are the
# build products generated by "make bootstrap", "make", and "make
# test". In this workflow, no commits should ever happen in this
# tree; it is purely for the convenience of testing since you will
# have a usable bootstrapped tree. (Of course if the changes from
# branch "fix1" to branch "fix2" would have broken the build and need
# a new "make bootstrap" under CVS, you'll need that here, too.)
Pending merges need to be committed or reverted before using
switch.
# The workflow described above should have no pending merges in this
# tree. The only VCS operation you do here after initialization is
# "bzr switch", which is sort of like "cvs update -r" for this workflow.
The path to the branch to switch to can be specified relative to
the parent directory of the current branch. For example, if you
are currently in a checkout of /path/to/branch, specifying
'newbranch' will find a branch at /path/to/newbranch.
# Don't you just love DWIM?
Bound branches use the nickname of its master branch unless it
is set locally, in which case switching will update the the
local nickname to be that of the master.
# I don't know what the above means, exactly; I don't use nicknames.
> Bazaar docs are not very clear on that, to say the least:
>
> Purpose: Create a new checkout of an existing branch.
>
> But fix$i is already an existing branch, and one with local changes,
> so this ``create'' seems not quite the right word here.
My bad, I did warn that my syntax might be wrong.
> (Btw, note the tricky convention regarding slashes, not for the faint
> of heart IMO.)
Heh. Emacsen users should be used to such things, though.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-01 10:04 ` Óscar Fuentes
@ 2010-01-02 15:44 ` Richard Stallman
0 siblings, 0 replies; 97+ messages in thread
From: Richard Stallman @ 2010-01-02 15:44 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
You can change anything on the history of your private branch using a
variety of techniques (being `bzr uncommit' the simplest one,) but we
have to admit that changing the message of an arbitrary revision is
something that can't be done due to the nature of DVCSs
How sad.
I wonder if we could provide a different feature which would
do the same job: namely, a way to enter a subsequent revision
which says, "This message replaces the commit message of revision N."
We could set it up so that the usual ways of looking at history
will do that edit, as if the commit message of revision N had been changed.
There would be an option to disable this automatic editing and show
things as they really are.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 15:30 ` Stephen J. Turnbull
@ 2010-01-02 17:05 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2010-01-02 17:05 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: lekktu, emacs-devel
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: lekktu@gmail.com,
> emacs-devel@gnu.org
> Date: Sun, 03 Jan 2010 00:30:44 +0900
>
> > > cd build-test
> > > make bootstrap
> > > make test # if you like, but should be OK :-)
> > > for i = 1 2 3; do
> > > cd ..
> > > bzr branch trunk fix$i
> > > cd fix$i
> > > # hack
> > > bzr commit -m "fix$i"
> > > cd ../build-test
>
> Oops, this is where I went WRONG:
>
> > > bzr checkout ../fix$i
>
> RIGHT:
>
> bzr switch ../fix$i
[snip]
Thanks, I'm saving these recipes for when I will need them.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 12:09 ` Miles Bader
@ 2010-01-02 19:22 ` Karl Fogel
2010-01-05 8:50 ` Stephen J. Turnbull
0 siblings, 1 reply; 97+ messages in thread
From: Karl Fogel @ 2010-01-02 19:22 UTC (permalink / raw
To: Miles Bader
Cc: ofv, Juanma Barranquero, emacs-devel, Andreas Schwab,
Stephen J. Turnbull, Teemu Likonen, Eli Zaretskii
Miles Bader <miles@gnu.org> writes:
>Nonetheless, IME, it's _extremely_ rare for it to represent a serious
>issue, and nowhere near enough of a problem to be worth the cost of such
>a mechanism.
I don't know how rare it is, but I saw it be important once. See
http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#contribulyzer
Search for the phrase
"after writing the Contribulyzer code to process log messages
formatted according to the new standard, we could go back and fix up
all of the project's existing logs to conform to that standard"
to jump straight to the paragraph about how editing log messages after
the fact made a big difference.
-Karl
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes?
2010-01-02 19:22 ` Karl Fogel
@ 2010-01-05 8:50 ` Stephen J. Turnbull
0 siblings, 0 replies; 97+ messages in thread
From: Stephen J. Turnbull @ 2010-01-05 8:50 UTC (permalink / raw
To: Karl Fogel
Cc: ofv, Juanma Barranquero, emacs-devel, Andreas Schwab,
Eli Zaretskii, Teemu Likonen, Miles Bader
Karl Fogel writes:
> Search for the phrase
>
> "after writing the Contribulyzer code to process log messages
> formatted according to the new standard, we could go back and fix up
> all of the project's existing logs to conform to that standard"
>
> to jump straight to the paragraph about how editing log messages after
> the fact made a big difference.
For something like that you could use git-filter-branch and probably
the equivalent in bzr (there *is* an equivalent, but I think it
requires converting to fastimport format to use). To avoid the rebase
issue, you'd maybe merge the resulting branch rather than rebase.
git-filter-branch is very fast, although bzr's equivalent would not be
if I'm correct about converting to fastimport format. But it could
probably be made to be fast.
^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2010-01-05 8:50 UTC | newest]
Thread overview: 97+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.