[Top][All Lists]
[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
- Re: reversion revulsion, (continued)
- Re: reversion revulsion, Thien-Thi Nguyen, 2010/01/08
- Re: reversion revulsion [was: log format for vc-bzr], Óscar Fuentes, 2010/01/08
- Re: reversion revulsion [was: log format for vc-bzr], Eli Zaretskii, 2010/01/08
- Re: reversion revulsion, Óscar Fuentes, 2010/01/08
- Re: reversion revulsion, Eli Zaretskii, 2010/01/08
- Re: reversion revulsion, Óscar Fuentes, 2010/01/08
- Re: reversion revulsion [was: log format for vc-bzr], Juanma Barranquero, 2010/01/08
- Re: reversion revulsion [was: log format for vc-bzr], Juanma Barranquero, 2010/01/08
- Re: log format for vc-bzr, Juanma Barranquero, 2010/01/08
- Re: log format for vc-bzr, Eli Zaretskii, 2010/01/08
- Re: log format for vc-bzr,
Juanma Barranquero <=
- Re: log format for vc-bzr, Eli Zaretskii, 2010/01/08
- Re: log format for vc-bzr, Juanma Barranquero, 2010/01/08
- Re: log format for vc-bzr, Andreas Schwab, 2010/01/08
- Re: log format for vc-bzr, Juanma Barranquero, 2010/01/08
- Re: log format for vc-bzr, Thien-Thi Nguyen, 2010/01/08
- bzr Q&A [was Re: log format for vc-bzr], Glenn Morris, 2010/01/08
- Re: bzr Q&A [was Re: log format for vc-bzr], Eli Zaretskii, 2010/01/09
- bzr Q&A [was Re: log format for vc-bzr], Stephen J. Turnbull, 2010/01/09
- Re: log format for vc-bzr, Stephen J. Turnbull, 2010/01/08
- Re: log format for vc-bzr, Eli Zaretskii, 2010/01/08