emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: log format for vc-bzr


From: Juanma Barranquero
Subject: Re: log format for vc-bzr
Date: Fri, 8 Jan 2010 13:24:29 +0100

On Fri, Jan 8, 2010 at 13:01, Eli Zaretskii <address@hidden> wrote:

> Thanks, but isn't this in the direction that is opposite of the one
> for which it was suggested?  I though you are supposed to use it
> _on_the_trunk_, after merging from a branch.  But you seem to show it
> in the other direction, which confuses this issue even more, at least
> for me.

I don't know what in my message (other than my usual clarity or lack
of it) makes you think that. I was talking about

   cd your-branch
   # hack hack hack
   bzr commit -m "..."
   cd ../trunk
   bzr merge ../your-branch
   bzr revert --pending-merges
   bzr commit -m "un-merged changes"

> So its effect is similar to that of rebasing?

Humm, no. Leaving aside uncommited changes, conflicts, etc., rebase
un-applies some commits, updates the branch, and reapplies these
commits as if they were new. "revert --pending-changes" is done on a
branch that has just been the target of a merge, and affects changes
that have not yet been committed.

> But the issue at hand was how to hide personal comments in the commit
> messages, not how to hide some of the intermediate changes.  Why would
> I want to do the latter?

Sorry, I don't follow what do you mean with "personal comments" vs.
"intermediate changes". I think Óscar meant that you have a branch
with several commits, some of them meaningful, some of them of the
"gone to lunch" variety, some reverting previous changes, etc., and
you can use merge (and in particular merge -c or merge -r) to move
commits to another branch, de-merge them (with revert
--forget-merges), fix them, and apply them to that new branch, so you
can reconstruct in the second branch a history of the first branch
totally to your liking (that including, of course, totally new commit
messages, and dropping the ones you don't like, or squashing several
original commits into one, splitting them, etc.). The result is
similar to what you could do in git with rebase (and rebase -i), but
less automatic.

    Juanma




reply via email to

[Prev in Thread] Current Thread [Next in Thread]