rebasing

rebasing

[Miles Bader]

[I posted this question to a thread in the ding (gnus) list, but thought
I'd ask it here too.]

One thing that concerns me is the anti-rebasing dogma that one hears
from canonical.  Does anybody know if it's just dogma, or does bzr
actually have technical problems with rebasing?

I ask because for the common small random commits case, it seems _much_
better to just commit to the trunk locally and rebase these local
commits on pulling from the main repository; the "keep N branches and
merge back and forth, even for trivial commits" recipe that is
apparently advocated for emacs seems like a huge annoyance.

-Miles

-- 
「すっごい」と呟いてる。「へんてこなもんばっかり」
「そんなにへんてこ？」
「へんてこへんてこ」
そう言われると見たくなってしまう。

Re: rebasing

[Stefan Monnier]

> One thing that concerns me is the anti-rebasing dogma that one hears
> from canonical.  Does anybody know if it's just dogma, or does bzr
> actually have technical problems with rebasing?

AFAIK, bzr supports rebase less well than Git, both in the sense that
it's a separate plugin, and in the sense that it really doesn't keep
track of the ancestry pre-rebase, contrary to Git which does keep some
info about it.  AFAIK, there's no deep reason for that.

As maintainer, I don't care if people rebase rather than merge before
installing changes from their local branch to the trunk.  It probably
results in cleaner patches/history, so it's fine by me.


        Stefan

Re: rebasing

[Karl Fogel]

Miles Bader <miles@gnu.org> writes:
>[I posted this question to a thread in the ding (gnus) list, but thought
>I'd ask it here too.]
>
>One thing that concerns me is the anti-rebasing dogma that one hears
>from canonical.  Does anybody know if it's just dogma, or does bzr
>actually have technical problems with rebasing?
>
>I ask because for the common small random commits case, it seems _much_
>better to just commit to the trunk locally and rebase these local
>commits on pulling from the main repository; the "keep N branches and
>merge back and forth, even for trivial commits" recipe that is
>apparently advocated for emacs seems like a huge annoyance.

I strongly recommend asking this question on the Bazaar list.  The
answers you get from the ding (gnus) list and from the Emacs list will
be heartfelt, I'm sure, but may miss some technicality that turns out to
be important.

Re: rebasing

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
> I strongly recommend asking this question on the Bazaar list.  The
> answers you get from the ding (gnus) list and from the Emacs list will
> be heartfelt, I'm sure, but may miss some technicality that turns out to
> be important.

I'm rather afraid of getting piled on, to be honest...

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: rebasing

[David Engster]

Miles Bader <miles@gnu.org> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>> I strongly recommend asking this question on the Bazaar list.  The
>> answers you get from the ding (gnus) list and from the Emacs list will
>> be heartfelt, I'm sure, but may miss some technicality that turns out to
>> be important.
>
> I'm rather afraid of getting piled on, to be honest...

Rebasing has been discussed on the Bazaar list before. For instance:

http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/56728
http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/62762

There are also some interesting blog posts, like

http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar
http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html

-David

Re: rebasing

[Stephen J. Turnbull]

Miles Bader writes:
 > Karl Fogel <kfogel@red-bean.com> writes:
 > > I strongly recommend asking this question on the Bazaar list.  The
 > > answers you get from the ding (gnus) list and from the Emacs list will
 > > be heartfelt, I'm sure, but may miss some technicality that turns out to
 > > be important.
 > 
 > I'm rather afraid of getting piled on, to be honest...

Don't be.  While some Bazaar folks (non-developers) will surely tell
you to stay away from rebase if possible, the developers will help you
do what you want.  And I think you know most of the important ones
from gnu-arch-users, anyway.

Re: rebasing

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

[snip]

In addition to what Stefan and Karl say...

> I ask because for the common small random commits case, it seems _much_
> better to just commit to the trunk locally and rebase these local
> commits on pulling from the main repository; the "keep N branches and
> merge back and forth, even for trivial commits" recipe that is
> apparently advocated for emacs seems like a huge annoyance.

I'm having trouble figuring out which kind of workflow would benefit
from this. Unless you work disconnected, or for some other reason wish
to send upstream your quick fixes on batches, how would you benefit from
`rebase'? If you work connected, just do your quick fixes on a branch
bound to upstream, then you essentially do the same sequence of
operations you used with CVS: update & commit, and everything with
VC-dir.

[Also, please note that the Rebase plugin for bzr does not support
git's --interactive]

Re: rebasing

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> I ask because for the common small random commits case, it seems _much_
>> better to just commit to the trunk locally and rebase these local
>> commits on pulling from the main repository; the "keep N branches and
>> merge back and forth, even for trivial commits" recipe that is
>> apparently advocated for emacs seems like a huge annoyance.
>
> I'm having trouble figuring out which kind of workflow would benefit
> from this. Unless you work disconnected, or for some other reason wish
> to send upstream your quick fixes on batches, how would you benefit from
> `rebase'? If you work connected, just do your quick fixes on a branch
> bound to upstream, then you essentially do the same sequence of
> operations you used with CVS: update & commit, and everything with
> VC-dir.

I don't understand what you're saying -- you mean I should give up local
commits, and just use CVS-style "commits go directly to the central
repo"?

Often the sort of commit I'm talking about is relatively short-lived and
ephemeral, but I usually do not want to commit to the central repo on
the spot, I'd rather commit stuff locally and let it live in my local
system for a while; I may or may not want to send it upstream or delete
it or whatever.

A rebase-on-pull-style workflow, gives some of the immediacy of a pure
CVS-style workflow, but still allows local commits / disconnection
operation / etc.  I.e.: good.

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: rebasing

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>>> I ask because for the common small random commits case, it seems _much_
>>> better to just commit to the trunk locally and rebase these local
>>> commits on pulling from the main repository; the "keep N branches and
>>> merge back and forth, even for trivial commits" recipe that is
>>> apparently advocated for emacs seems like a huge annoyance.
>>
>> I'm having trouble figuring out which kind of workflow would benefit
>> from this. Unless you work disconnected, or for some other reason wish
>> to send upstream your quick fixes on batches, how would you benefit from
>> `rebase'? If you work connected, just do your quick fixes on a branch
>> bound to upstream, then you essentially do the same sequence of
>> operations you used with CVS: update & commit, and everything with
>> VC-dir.
>
> I don't understand what you're saying -- you mean I should give up local
> commits, and just use CVS-style "commits go directly to the central
> repo"?

No.

> Often the sort of commit I'm talking about is relatively short-lived and
> ephemeral, but I usually do not want to commit to the central repo on
> the spot, I'd rather commit stuff locally and let it live in my local
> system for a while; I may or may not want to send it upstream or delete
> it or whatever.
>
> A rebase-on-pull-style workflow, gives some of the immediacy of a pure
> CVS-style workflow, but still allows local commits / disconnection
> operation / etc.  I.e.: good.

Agreed. However, you will find that bzr's support for this is quite weak
compared to git. First, as previously said, bzr's `rebase' is very
simple, do `bzr help rebase' and check it yourself. Second, bzr does not
track merges of specific revisions. This causes that sending upstream a
selected set of revisions or discarding some others from your local
branch are delicate and lengthy operations.

Re: rebasing

[Stephen J. Turnbull]

Miles Bader writes:

 > Often the sort of commit I'm talking about is relatively short-lived and
 > ephemeral, but I usually do not want to commit to the central repo on
 > the spot, I'd rather commit stuff locally and let it live in my local
 > system for a while; I may or may not want to send it upstream or delete
 > it or whatever.

You may want looms or pipelines, then.

 > A rebase-on-pull-style workflow, gives some of the immediacy of a pure
 > CVS-style workflow, but still allows local commits / disconnection
 > operation / etc.  I.e.: good.

The only way to do that in Bazaar as far as I know is to maintain a
separate branch for your local changes.  If you have multiple sets of
such changes, you'll need multiple branches, one for each set.  And
you would do it not by pulling, but by merging from trunk into your
branch.  You'd probably need to cherrypick patches out of that, not
rebase on to trunk (ie, sending stuff upstream will not get full
support from the VCS).

Re: rebasing

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Thu, 28 Jan 2010 22:57:57 +0900
> Cc: emacs-devel@gnu.org
> 
> I don't understand what you're saying -- you mean I should give up local
> commits, and just use CVS-style "commits go directly to the central
> repo"?

Not necessarily.  You could always commit locally with "bzr ci --local".

Rebasing (was: [Emacs-diffs] feature/gnus-select 46738e3 040/218: Improve SVG documentation)

[Stefan Monnier]

Hi Andrew,

I see you pushed changes to the gnus-select branch, but in this push
I see many (many) commits and I'm having trouble seeing the ones *you*
made: most of the commits are like the one below.

It looks like you did some kind of rebasing, but in a way that rebased
other people's changes on top of yours rather than the opposite.

Is that indeed that you've done?
Is there a specific reason for that, or was an accident?


        Stefan


cohen@andy.bu.edu (Andrew G Cohen) writes:

> branch: feature/gnus-select
> commit 46738e3765ff22f73272ad75c5aea9385de7da33
> Author: Charles A. Roelli <charles@aurox.ch>
> Commit: Andrew G Cohen <cohen@andy.bu.edu>
>
>     Improve SVG documentation
>     
>     * doc/lispref/display.texi (ImageMagick Images): Remove an
>     outdated comment that references a fixed bug.
>     (SVG Images): Fix grammar, and call functions functions (there are
>     no commands in lisp/svg.el).
> ---
>  doc/lispref/display.texi | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
> index dcd2fcf..2ac89ba 100644
> --- a/doc/lispref/display.texi
> +++ b/doc/lispref/display.texi
> @@ -5387,7 +5387,6 @@ hint to ImageMagick to help it detect the image type.
>  Specifies a rotation angle in degrees.
>  
>  @item :index @var{frame}
> -@c Doesn't work: https://debbugs.gnu.org/7978
>  @xref{Multi-Frame Images}.
>  @end table
>  
> @@ -5396,8 +5395,8 @@ Specifies a rotation angle in degrees.
>  @cindex SVG images
>  
>  SVG (Scalable Vector Graphics) is an XML format for specifying images.
> -If your Emacs build has with SVG support, you can create and manipulate
> -these images with the following commands.
> +If your Emacs build has SVG support, you can create and manipulate
> +these images with the following functions.
>  
>  @defun svg-create width height &rest args
>  Create a new, empty SVG image with the specified dimensions.
> @@ -5411,7 +5410,7 @@ The default width (in pixels) of any lines created.
>  The default stroke color on any lines created.
>  @end table
>  
> -This function returns an SVG structure, and all the following commands
> +This function returns an SVG structure, and all the following functions
>  work on that structure.
>  @end defun
>  
>
> _______________________________________________
> Emacs-diffs mailing list
> Emacs-diffs@gnu.org
> https://lists.gnu.org/mailman/listinfo/emacs-diffs

Re: Rebasing

[Andrew Cohen]

Following my blunder in trying to update the feature/gnus-select branch,
Stefan has helped me restore things to a sane state. Since this branch
was so far out of sync with master, I ended up creating a new branch,
feature/gnus-select2, with may changes rebased off of master from a few
days ago. I'll delete the obsolete feature/gnus-select branch shortly.

Sorry for the trouble.

Re: Rebasing

[Eric Abrahamsen]

Andrew Cohen <cohen@bu.edu> writes:

> Following my blunder in trying to update the feature/gnus-select branch,
> Stefan has helped me restore things to a sane state. Since this branch
> was so far out of sync with master, I ended up creating a new branch,
> feature/gnus-select2, with may changes rebased off of master from a few
> days ago. I'll delete the obsolete feature/gnus-select branch shortly.

I'm looking forward to seeing this land!