Installing changes from branches

Installing changes from branches

[Stefan Monnier]

I noticed recently that some people install small changes
from "quickfix branches" by something like:

  cd .../trunk
  bzr merge .../quickfix
  bzr commit ...

This is fine if the quickfix has only a single commit or OTOH is a long
running branch with many different real commits.  But not if the branch
has barely more than 1 real commit plus various "merge from trunk".
E.g.:

   revno: 99807 [merge]
   committer: Jan D. <jan.h.d@swipnet.se>
   branch nick: trunk
   timestamp: Fri 2010-04-02 11:46:07 +0200
   message:
     * tmm.el (tmm-get-keymap): Check with symbolp before passing value to fboundp.
       ------------------------------------------------------------
       revno: 99248.1.60 [merge]
       committer: Jan D. <jan.h.d@swipnet.se>
       branch nick: fixes
       timestamp: Fri 2010-04-02 11:45:27 +0200
       message:
         Merge from trunk
       ------------------------------------------------------------
       revno: 99248.1.59
       committer: Jan D. <jan.h.d@swipnet.se>
       branch nick: fixes
       timestamp: Fri 2010-04-02 11:44:50 +0200
       message:
         tmm.el (tmm-get-keymap): Check with symbolp before passing
         value to fboundp, it may not be a symbol.
       ------------------------------------------------------------
       revno: 99248.1.58 [merge]
       committer: Jan D. <jan.h.d@swipnet.se>
       branch nick: fixes
       timestamp: Thu 2010-04-01 08:50:44 +0200
       message:
         Merge from trunk
       ------------------------------------------------------------
       revno: 99248.1.57 [merge]
       committer: Jan D. <jan.h.d@swipnet.se>
       branch nick: fixes
       timestamp: Fri 2010-03-26 08:01:19 +0100
       message:
         Merge from trunk
       ------------------------------------------------------------
       revno: 99248.1.56 [merge]
       committer: Jan D. <jan.h.d@swipnet.se>
       branch nick: fixes
       timestamp: Tue 2010-03-23 20:32:31 +0100
       message:
         Merge from trunk
       ------------------------------------------------------------
       revno: 99248.1.55 [merge]
       committer: Jan D. <jan.h.d@swipnet.se>
       branch nick: fixes
       timestamp: Tue 2010-03-23 08:04:35 +0100
       message:
         Merge from trunk

[ Please Jan, don't take it personally, it's just an example. ]
For such changes, it's a lot better to just take the diff from the
branch, apply to the trunk and commit, so it appears as a single commit.
Yes, it loses the history, but that's a good thing.  Those "merge from
trunk" are just personal history that are just noise.  Especially since
some people call them "Merge from trunk" others "Merge from mainline"
etc...

A better way is probably to keep such quickfix branches out-of-date
(i.e. never do a "merge from trunk" in them), so the "update to trunk"
is then done when you do "bzr merge .../quickfix".  Or to use "bzr
rebase" instead.

Another very good solution is to not use quickfix branches at all, but
use shelves instead.  I.e. write your fix "on the trunk" but instead of
committing it, just do "bzr shelve -m 'fix for foo'".
Then when you're ready to install the fix just unshelve the fix and
commit it.


        Stefan

Re: Installing changes from branches

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I noticed recently that some people install small changes
> from "quickfix branches" by something like:
>
>   cd .../trunk
>   bzr merge .../quickfix
>   bzr commit ...
>
> This is fine if the quickfix has only a single commit or OTOH is a long
> running branch with many different real commits.  But not if the branch
> has barely more than 1 real commit plus various "merge from trunk".
> E.g.:

[snip]

> Another very good solution is
[snip]

And there is yet another solution, which is to bind the quickfixes
branch to upstream. Instead of `bzr merge', do `bzr update'. When you
finish a change, `bzr commit' will send it automatically upstream.

Re: Installing changes from branches

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 03 Apr 2010 03:37:41 +0200
> 
> And there is yet another solution, which is to bind the quickfixes
> branch to upstream. Instead of `bzr merge', do `bzr update'. When you
> finish a change, `bzr commit' will send it automatically upstream.

But then why have a separate branch for that?  This is precisely the
workflow in `trunk'.  What am I missing?

Re: Installing changes from branches

[Stefan Monnier]

> But then why have a separate branch for that?  This is precisely the
> workflow in `trunk'.  What am I missing?

No reason, indeed.  Just a separate checkout.


        Stefan

Re: Installing changes from branches

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> And there is yet another solution, which is to bind the quickfixes
>> branch to upstream. Instead of `bzr merge', do `bzr update'. When you
>> finish a change, `bzr commit' will send it automatically upstream.
>
> But then why have a separate branch for that?  This is precisely the
> workflow in `trunk'.  What am I missing?

Although you can use `trunk' for that, I prefer to avoid overloading too
much the purpose of things. `trunk' is your pristine upstream's mirror
and the gateway for merging local changes into upstream. There are cases
where using `trunk' for hacking can create inconveniences (not very
serious incoveniences, though).

For instance, if you begin hacking into something that seems easy but
later discover that it is a deeper issue, turning `quickfixes' into a
feature branch is trivial. If you were working on `trunk' you'll need to
create a feature branch and merge `trunk's uncommitted changes into it,
which may be tricky on some cases, as if you have new unregistered
files.

Another scenario that can be a bit tricky to handle if you use `trunk'
for hacking is when you go off-line for a while and end accumulating a
series of local commits of quickfixes on `trunk'

Re: Installing changes from branches

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 03 Apr 2010 16:19:23 +0200
> 
> For instance, if you begin hacking into something that seems easy but
> later discover that it is a deeper issue, turning `quickfixes' into a
> feature branch is trivial.

How is that trivial?  It's a bound branch under your suggestion.  "bzr
unbind" is not exactly a common command, and the wiki warns:
"Unbinding has some unintuitive consequences; be careful."

Or did you mean something else?

> If you were working on `trunk' you'll need to
> create a feature branch and merge `trunk's uncommitted changes into it,
> which may be tricky on some cases, as if you have new unregistered
> files.

   cd ..
   bzr branch trunk fix-something
   cd fix-something
   bzr merge ../trunk --uncommitted
   cd ../trunk
   bzr revert
   cd ../fix-something
   [and hack in the branch]

If by ``unregistered files'' you mean files not yet added to bzr, then
the above sequence of commands is not much more complicated.

Most importantly, one needs to _think_ before they start hacking, and
one of the important questions to ask oneself is "is this change
really a quickie?".

So I still maintain that having two branches bound to trunk is going
to be pure useless overhead, most of the time.  YMMV, of course.

Re: Installing changes from branches

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> For instance, if you begin hacking into something that seems easy but
>> later discover that it is a deeper issue, turning `quickfixes' into a
>> feature branch is trivial.
>
> How is that trivial?

bzr unbind
cd ..
mv quickfixes my-bugfix

> It's a bound branch under your suggestion.  "bzr
> unbind" is not exactly a common command, and the wiki warns:
> "Unbinding has some unintuitive consequences; be careful."

Without more explanation, the above warning is just a weak hint about
Bazaar's quality.

[snip]

Re: Installing changes from branches

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 03 Apr 2010 17:14:36 +0200
> 
> > It's a bound branch under your suggestion.  "bzr
> > unbind" is not exactly a common command, and the wiki warns:
> > "Unbinding has some unintuitive consequences; be careful."
> 
> Without more explanation, the above warning is just a weak hint about
> Bazaar's quality.

I didn't write that note, so I have no idea what it means and what
``unintuitive consequences'' are being referred to.

Re: Installing changes from branches

[Juanma Barranquero]

> I noticed recently that some people install small changes
> from "quickfix branches" by something like:
>
>  cd .../trunk
>  bzr merge .../quickfix
>  bzr commit ...
>
> This is fine if the quickfix has only a single commit or OTOH is a long
> running branch with many different real commits.  But not if the branch
> has barely more than 1 real commit plus various "merge from trunk".

Well, I usually do merges to trunk composed of two or more commits
with typo fixes (though I never do "merge from trunk" in these). Do
you want them as separate commits?

    Juanma

Re: Installing changes from branches

[Jan Djärv]

Stefan Monnier skrev 2010-04-03 03.05:
> I noticed recently that some people install small changes
> from "quickfix branches" by something like:
>
>    cd .../trunk
>    bzr merge .../quickfix
>    bzr commit ...
>
> This is fine if the quickfix has only a single commit or OTOH is a long
> running branch with many different real commits.  But not if the branch
> has barely more than 1 real commit plus various "merge from trunk".
> E.g.:
>
>     revno: 99807 [merge]
>     committer: Jan D.<jan.h.d@swipnet.se>
>     branch nick: trunk
>     timestamp: Fri 2010-04-02 11:46:07 +0200
>     message:
>       * tmm.el (tmm-get-keymap): Check with symbolp before passing value to fboundp.
>         ------------------------------------------------------------
>         revno: 99248.1.60 [merge]
>         committer: Jan D.<jan.h.d@swipnet.se>
>         branch nick: fixes
>         timestamp: Fri 2010-04-02 11:45:27 +0200
>         message:
>           Merge from trunk
>         ------------------------------------------------------------
>         revno: 99248.1.59
>         committer: Jan D.<jan.h.d@swipnet.se>
>         branch nick: fixes
>         timestamp: Fri 2010-04-02 11:44:50 +0200
>         message:
>           tmm.el (tmm-get-keymap): Check with symbolp before passing
>           value to fboundp, it may not be a symbol.
>         ------------------------------------------------------------
>         revno: 99248.1.58 [merge]
>         committer: Jan D.<jan.h.d@swipnet.se>
>         branch nick: fixes
>         timestamp: Thu 2010-04-01 08:50:44 +0200
>         message:
>           Merge from trunk
>         ------------------------------------------------------------
>         revno: 99248.1.57 [merge]
>         committer: Jan D.<jan.h.d@swipnet.se>
>         branch nick: fixes
>         timestamp: Fri 2010-03-26 08:01:19 +0100
>         message:
>           Merge from trunk
>         ------------------------------------------------------------
>         revno: 99248.1.56 [merge]
>         committer: Jan D.<jan.h.d@swipnet.se>
>         branch nick: fixes
>         timestamp: Tue 2010-03-23 20:32:31 +0100
>         message:
>           Merge from trunk
>         ------------------------------------------------------------
>         revno: 99248.1.55 [merge]
>         committer: Jan D.<jan.h.d@swipnet.se>
>         branch nick: fixes
>         timestamp: Tue 2010-03-23 08:04:35 +0100
>         message:
>           Merge from trunk
>
> [ Please Jan, don't take it personally, it's just an example. ]

That is OK.  I didn't even know comments got merged like this.
Isn't the real problem that bzr requires a commit in the quickfix branch after 
a merge?  If you are doing some work that takes time, I find it easier to 
merge from the trunk from time to time, rather than taking a big hit at the end.

Something like a collapsed merge would be good, i.e. merge from quickfix, but 
only record it as a single commit.

	Jan D.

Re: Installing changes from branches

[Stephen J. Turnbull]

Jan Djärv writes:

 > Something like a collapsed merge would be good, i.e. merge from
 > quickfix, but only record it as a single commit.

That's "cherry-picking."  bzr doesn't do that terribly well.

A cosmetic workaround is to use "bzr log -n 1" (which I AFAIK is the
default) to get that view.  (That may be why you weren't aware of all
the additional log messages.)  The problem with that is that core
maintainers (especially release managers) are going to use
"full-depth" logs ("bzr log -n 0") to get a more detailed view of what
people are actually doing.  It probably doesn't solve this problem.

The following options are available, I think:

  - the "loom" extension; this is like a mating of Andrew Morton's
    quilt and Mercurial queues on steroids; undocumented
  - the "rewrite" (aka rebase) extension (designed for cherrypicking,
    but not great and not well-documented lask I looked)
  - the "pipeline" extension (very similar to Mercurial queues);
    undocumented
  - the "shelve" feature (a one-off way to save incomplete work)

Sorry I don't have time to go into detail.

Re: Installing changes from branches

[Stefan Monnier]

> That is OK.  I didn't even know comments got merged like this.
> Isn't the real problem that bzr requires a commit in the quickfix branch
> after a merge?

Bzr doesn't require any such thing.  You decided to commit, not bzr.
That's linked to the fact that you decided to use "merge" rather than
"pull", i.e. use a separate branch.

> If you are doing some work that takes time, I find it easier to merge
> from the trunk from time to time, rather than taking a big hit at
> the end.

There are many different ways to do it.  I suggested a few in the part
of the message you elided:
- "For such changes, it's a lot better to just take the diff from the
  branch, apply to the trunk and commit".  That's what I do, as a matter
  of fact, and I have grown to like it, since this "diff&patch" is
  a good opportunity to rework/cleanup the patch one last time before
  committing it.
- "Or to use "bzr rebase" instead".
- "Another very good solution is to not use quickfix branches at all, but
  use shelves instead".

> Something like a collapsed merge would be good, i.e. merge from quickfix,
> but only record it as a single commit.

Indeed, you can also do that:

  cd .../trunk
  bzr merge .../quickfix
  bzr revert --forget-merges
  bzr commit ...

that's virtually the same as "diff&patch": it forgets all about the
branch's history.


        Stefan

Re: Installing changes from branches

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[snip]

>> Something like a collapsed merge would be good, i.e. merge from quickfix,
>> but only record it as a single commit.
>
> Indeed, you can also do that:
>
>   cd .../trunk
>   bzr merge .../quickfix
>   bzr revert --forget-merges
>   bzr commit ...
>
> that's virtually the same as "diff&patch": it forgets all about the
> branch's history.

This requires to reset the `quickfix' branch afterwards, or the next
time it will merge the same changes again. So the full sequence would be
(untested):

  cd .../trunk
  bzr merge .../quickfix
  bzr revert --forget-merges
  bzr commit ...
  cd .../quickfix
  bzr pull --overwrite

The last command discards the local changes made on `quickfix' and makes
that branch a clone of `trunk'

Re: Installing changes from branches

[Jan Djärv]

Stefan Monnier skrev 2010-04-03 16.08:
>> That is OK.  I didn't even know comments got merged like this.
>> Isn't the real problem that bzr requires a commit in the quickfix branch
>> after a merge?
>
> Bzr doesn't require any such thing.  You decided to commit, not bzr.

It is what the wiki-page says, I'm only following orders :-).
Anyway, I think bzr requires a commit before next merge.  Maybe there is some 
--force option to circumvent that.

> That's linked to the fact that you decided to use "merge" rather than
> "pull", i.e. use a separate branch.
>

I just decided to follow the instructions on the wiki page, pull isn't 
mentioned as an alternative there.

>> If you are doing some work that takes time, I find it easier to merge
>> from the trunk from time to time, rather than taking a big hit at
>> the end.
>
> There are many different ways to do it.  I suggested a few in the part
> of the message you elided:
> - "For such changes, it's a lot better to just take the diff from the
>    branch, apply to the trunk and commit".  That's what I do, as a matter
>    of fact, and I have grown to like it, since this "diff&patch" is
>    a good opportunity to rework/cleanup the patch one last time before
>    committing it.
> - "Or to use "bzr rebase" instead".
> - "Another very good solution is to not use quickfix branches at all, but
>    use shelves instead".

Rebase sounds good.  Doing diff and patch manually kind of feels like bzr is 
missing something.

>
>> Something like a collapsed merge would be good, i.e. merge from quickfix,
>> but only record it as a single commit.
>
> Indeed, you can also do that:
>
>    cd .../trunk
>    bzr merge .../quickfix
>    bzr revert --forget-merges
>    bzr commit ...
>
> that's virtually the same as "diff&patch": it forgets all about the
> branch's history.

But according to Óscar Fuentes you must later overwrite your quickfix branch 
with a pull --overwrite.  I assume you loose local history on the quickfix 
branch then?

It is all very confusing.

	Jan D.

Re: Installing changes from branches

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

[snip]

>> Indeed, you can also do that:
>>
>>    cd .../trunk
>>    bzr merge .../quickfix
>>    bzr revert --forget-merges
>>    bzr commit ...
>>
>> that's virtually the same as "diff&patch": it forgets all about the
>> branch's history.
>
> But according to Óscar Fuentes you must later overwrite your quickfix
> branch with a pull --overwrite.  I assume you loose local history on
> the quickfix branch then?

Yes. After the `bzr pull --overwrite' the quickfixes branch becomes
identical to `trunk'. Hopefully, for quick fixes the local history is
not something so valuable that you want to keep it around. Furthermore,
a quick fix is usually made of a single commit, so you end mapping your
local commit on `quickfixes' to a single commit on `trunk', which
lessens the history loss.

> It is all very confusing.

Indeed. Bazaar chose to provide a multitude of workflows without
requiring an understanding of its fundamental model (which is quite
simple.) It is like pretending from someone to learn how to pilot a
Jumbo without knowing the purpose of the airplane's wings and tail.

Re: Installing changes from branches

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 03 Apr 2010 17:41:59 +0200
> 
> Yes. After the `bzr pull --overwrite' the quickfixes branch becomes
> identical to `trunk'. Hopefully, for quick fixes the local history is
> not something so valuable that you want to keep it around. Furthermore,
> a quick fix is usually made of a single commit, so you end mapping your
> local commit on `quickfixes' to a single commit on `trunk', which
> lessens the history loss.

If the fix takes only one commit, IMO it doesn't deserve a separate
branch.

FWIW, I have two kinds of branches that I use in different workflows:

  . A feature branch, where I work on some really non-trivial
    feature.  The bidi branch is a good example.  This kind of branch
    lives for a relatively long time, and is not necessarily removed
    when a feature is delivered (a.k.a. ``landed'') on the trunk --
    because the delivery may very well be in several stages.

    On this kind of branch, I merge back from the trunk as soon as I
    deliver a feature to the trunk.  Then I continue working on that
    branch, until the next delivery.

    The history of this kind of branch is very precious for me, and I
    never want to lose it.

  . A testing branch, where I test various small changes and features
    before installing them on the trunk.  The workflow on this kind of
    branch usually goes like this:

      cd ../test
      bzr merge --pull
      [hack away, test, hack some more, until ready to go public]
      bzr diff > ../foo
      cd ../trunk
      bzr up
      patch < ../foo
      bzr ci -m "whatever"
      [re-sync the branch with he trunk, be ready for the next hack]
      cd ../test
      bzr revert
      bzr merge --pull

    As you may have guessed, the history on this branch is not
    important at all, once I deliver the changes to the trunk.

    And no, I don't consider use of `patch' outside of bzr a sign that
    something is wrong.

Re: Installing changes from branches

[Eli Zaretskii]

> Date: Sat, 03 Apr 2010 19:29:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>       cd ../test
>       bzr merge --pull
>       [hack away, test, hack some more, until ready to go public]
>       bzr diff > ../foo

One possible variation at this point, important if I made local
commits to the test branch while working on this particular feature:

   bzr diff -rsubmit: > ../foo

The revision designated by `submit:' is the last common ancestor
between the trunk and the test branch, i.e. the last point where I
last re-synced with the trunk.  This is exactly the changes I made
that are not on the trunk.

Re: Installing changes from branches

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 03 Apr 2010 19:29:56 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>>       cd ../test
>>       bzr merge --pull
>>       [hack away, test, hack some more, until ready to go public]
>>       bzr diff > ../foo
>
> One possible variation at this point, important if I made local
> commits to the test branch while working on this particular feature:
>
>    bzr diff -rsubmit: > ../foo
>
> The revision designated by `submit:' is the last common ancestor
> between the trunk and the test branch, i.e. the last point where I
> last re-synced with the trunk.  This is exactly the changes I made
> that are not on the trunk.

If you use `bzr diff' and `patch' for incorporating your changes into
`trunk', bzr is unable to track. So you `bzr diff -rsubmit:' will
generate a diff as if you had never incorporated your local changes into
`trunk'.

Re: Installing changes from branches

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 03 Apr 2010 18:56:41 +0200
> 
> If you use `bzr diff' and `patch' for incorporating your changes into
> `trunk', bzr is unable to track.

I obviously failed to drive the point home: in this workflow, I don't
_want_ bzr to track these changes.  I want them to look like changes
I made directly on the trunk.

> So you `bzr diff -rsubmit:' will generate a diff as if you had never
> incorporated your local changes into `trunk'.

After invoking `patch', there's a commit, so how can you say I never
"incorporated the changes into `trunk'"?  Perhaps you mean "merge"
instead of "incorporate".  In the latter case, that's exactly what I
want: it does what Stefan asked for -- avoid numerous merge commits on
the trunk when they bear no importance (due to insignificant amount of
real changes).

Re: Installing changes from branches

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>> So you `bzr diff -rsubmit:' will generate a diff as if you had never
>> incorporated your local changes into `trunk'.
>
> After invoking `patch', there's a commit, so how can you say I never
> "incorporated the changes into `trunk'"?

Please note the "as if" in my wording.

[snip]

Re: Installing changes from branches

[Stefan Monnier]

>    bzr diff -rsubmit: > ../foo

> The revision designated by `submit:' is the last common ancestor
> between the trunk and the test branch,

Actually, IIUC (and last time I checked) this is not quite true, it's
just a diff w.r.t the head of the branch from which you merge.
I.e. if this "upstream" branch has been updated since you last merged,
the diff will include the new changes on the "upstream" branch.  :-(

Hopefully someone will tell me I'm wrong,


        Stefan

Re: Installing changes from branches

[Juanma Barranquero]

On Sat, Apr 3, 2010 at 21:14, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Actually, IIUC (and last time I checked) this is not quite true, it's
> just a diff w.r.t the head of the branch from which you merge.
> I.e. if this "upstream" branch has been updated since you last merged,
> the diff will include the new changes on the "upstream" branch.  :-(
>
> Hopefully someone will tell me I'm wrong,

I haven't tested it, but that's not what the doc (bzr help revisionspec) says:

submit:

    Diffing against this shows all the changes that were made in this branch,
    and is a good predictor of what merge will do.  The submit branch is
    used by the bundle and merge directive commands.  If no submit branch
    is specified, the parent branch is used instead.

    The common ancestor is the last revision that existed in both
    branches. Usually this is the branch point, but it could also be
    a revision that was merged.

    Examples:

      $ bzr diff -r submit:


    Juanma

Re: Installing changes from branches

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 3 Apr 2010 21:31:16 +0200
> Cc: ofv@wanadoo.es, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On Sat, Apr 3, 2010 at 21:14, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> > Actually, IIUC (and last time I checked) this is not quite true, it's
> > just a diff w.r.t the head of the branch from which you merge.
> > I.e. if this "upstream" branch has been updated since you last merged,
> > the diff will include the new changes on the "upstream" branch.  :-(
> >
> > Hopefully someone will tell me I'm wrong,
> 
> I haven't tested it, but that's not what the doc (bzr help revisionspec) says:

I use it all the time, and AFAICS it behaves exactly like the doc
says.

Re: Installing changes from branches

[Juri Linkov]

>> bzr diff -r submit:
>
> I use it all the time, and AFAICS it behaves exactly like the doc
> says.

Unfortunately, this useful bzr command is not supported by VC.

In PCL-CVS there was a set of diff commands with keybindings
and some of them are like "bzr diff -r submit":

(info "(pcl-cvs) Viewing differences")

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Installing changes from branches

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 04 Apr 2010 01:57:31 +0300
> Cc: ofv@wanadoo.es, Juanma Barranquero <lekktu@gmail.com>,
> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> bzr diff -r submit:
> >
> > I use it all the time, and AFAICS it behaves exactly like the doc
> > says.
> 
> Unfortunately, this useful bzr command is not supported by VC.

What is not supported by VC: "bzr diff" or revision spec such as
"submit:"?  (Note that the colon is important.)

I just did "C-u C-x v = submit: RET RET", and it did work for me.

Re: Installing changes from branches

[Juri Linkov]

>> >> bzr diff -r submit:
>> >
>> > I use it all the time, and AFAICS it behaves exactly like the doc
>> > says.
>>
>> Unfortunately, this useful bzr command is not supported by VC.
>
> What is not supported by VC: "bzr diff" or revision spec such as
> "submit:"?  (Note that the colon is important.)
>
> I just did "C-u C-x v = submit: RET RET", and it did work for me.

It produces a different command line because it asks for a newer
revision.  Maybe for the default revision the result will be the same,
but I need to specify the command line exactly as I want, and sometimes
add more switches.  For example, switching between context and unified
formats is a pain.  You have to manually change the value of the variable
`vc-bzr-diff-switches' before typing `C-x v ='.

I think, `rgrep' has a good UI for this functionality where
`C-u rgrep' asks for common options and before running the
constructed command allows to edit it.  And `C-u C-u rgrep'
allows to write the command line immediately.

Is this UI desirable for VC?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Installing changes from branches

[Stefan Monnier]

> I just did "C-u C-x v = submit: RET RET", and it did work for me.

You can just do C-u C-x v = s TAB RET RET.


        Stefan

Re: Installing changes from branches

[Stefan Monnier]

>> Actually, IIUC (and last time I checked) this is not quite true, it's
>> just a diff w.r.t the head of the branch from which you merge.
>> I.e. if this "upstream" branch has been updated since you last merged,
>> the diff will include the new changes on the "upstream" branch.  :-(
>> Hopefully someone will tell me I'm wrong,
> I haven't tested it, but that's not what the doc (bzr help
> revisionspec) says:

I don't see anything in the text you quoted that says that
"diff -rsubmit:" will shows the diff w.r.t. the common ancestor.

I just checked again, and sure enough it doesn't use the common ancestor:

   % bzr diff -rsubmit: | md5sum
   Using submit branch file:///home/monnier/src/emacs/bzr/emacs-23/
   e54805e84bf14fa7f4b1a9eab6fdd03a  -
   % bzr diff -r ../emacs-23 | md5sum 
   e54805e84bf14fa7f4b1a9eab6fdd03a  -
   % (cd ../emacs-23/; bzr update)
   [...]
   All changes applied successfully.
   Updated to revision 99717 of branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/emacs-23
   % bzr diff -rsubmit: | md5sum
   Using submit branch file:///home/monnier/src/emacs/bzr/emacs-23/
   6ffa596930696c7bd2514a2aa28be348  -
   %


-- Stefan

Re: Installing changes from branches

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Sun, 04 Apr 2010 10:18:32 -0400
> 
> I don't see anything in the text you quoted that says that
> "diff -rsubmit:" will shows the diff w.r.t. the common ancestor.

I don't understand your evidence (feel free to explain), but the bzr
docs does say that:

  submit: Selects a common ancestor with the submit branch. 

  submit: Diffing against this shows all the changes that were made in
          this branch, and is a good predictor of what merge will
          do. The submit branch is used by the bundle and merge
          directive commands. If no submit branch is specified, the
          parent branch is used instead.

          The common ancestor is the last revision that existed in
          both branches. Usually this is the branch point, but it
          could also be a revision that was merged. 

Re: Installing changes from branches

[Stefan Monnier]

>> I don't see anything in the text you quoted that says that
>> "diff -rsubmit:" will shows the diff w.r.t. the common ancestor.
> I don't understand your evidence (feel free to explain), but the bzr
> docs does say that:

Indeed, you're right.  I had merged elsewhere and my emacs-23 was simply
out-of-date.  I'm happy to report that it does indeed what you claim
(and what I want) it does.


        Stefan

Re: Installing changes from branches

[Juanma Barranquero]

On Sun, Apr 4, 2010 at 16:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I don't see anything in the text you quoted that says that
> "diff -rsubmit:" will shows the diff w.r.t. the common ancestor.

No, but it does say that "shows all the changes that were made in this
branch", which I think is what Eli wanted.

And you said:

> if this "upstream" branch has been updated since you last merged,
> the diff will include the new changes on the "upstream" branch.

which I think it's not true.

    Juanma