unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* rebasing
@ 2010-01-28  1:53 Miles Bader
  2010-01-28  2:54 ` rebasing Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Miles Bader @ 2010-01-28  1:53 UTC (permalink / raw)
  To: emacs-devel

[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

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28  1:53 rebasing Miles Bader
@ 2010-01-28  2:54 ` Stefan Monnier
  2010-01-28  5:08 ` rebasing Karl Fogel
  2010-01-28 11:33 ` rebasing Óscar Fuentes
  2 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2010-01-28  2:54 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28  1:53 rebasing Miles Bader
  2010-01-28  2:54 ` rebasing Stefan Monnier
@ 2010-01-28  5:08 ` Karl Fogel
  2010-01-28 13:59   ` rebasing Miles Bader
  2010-01-28 11:33 ` rebasing Óscar Fuentes
  2 siblings, 1 reply; 13+ messages in thread
From: Karl Fogel @ 2010-01-28  5:08 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28  1:53 rebasing Miles Bader
  2010-01-28  2:54 ` rebasing Stefan Monnier
  2010-01-28  5:08 ` rebasing Karl Fogel
@ 2010-01-28 11:33 ` Óscar Fuentes
  2010-01-28 13:57   ` rebasing Miles Bader
  2 siblings, 1 reply; 13+ messages in thread
From: Óscar Fuentes @ 2010-01-28 11:33 UTC (permalink / raw)
  To: emacs-devel

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]





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28 11:33 ` rebasing Óscar Fuentes
@ 2010-01-28 13:57   ` Miles Bader
  2010-01-28 14:42     ` rebasing Óscar Fuentes
                       ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Miles Bader @ 2010-01-28 13:57 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel

Ó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.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28  5:08 ` rebasing Karl Fogel
@ 2010-01-28 13:59   ` Miles Bader
  2010-01-28 14:28     ` rebasing David Engster
  2010-01-28 14:53     ` rebasing Stephen J. Turnbull
  0 siblings, 2 replies; 13+ messages in thread
From: Miles Bader @ 2010-01-28 13:59 UTC (permalink / raw)
  To: Karl Fogel; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28 13:59   ` rebasing Miles Bader
@ 2010-01-28 14:28     ` David Engster
  2010-01-28 14:53     ` rebasing Stephen J. Turnbull
  1 sibling, 0 replies; 13+ messages in thread
From: David Engster @ 2010-01-28 14:28 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28 13:57   ` rebasing Miles Bader
@ 2010-01-28 14:42     ` Óscar Fuentes
  2010-01-28 15:06     ` rebasing Stephen J. Turnbull
  2010-01-28 18:41     ` rebasing Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Óscar Fuentes @ 2010-01-28 14:42 UTC (permalink / raw)
  To: emacs-devel

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28 13:59   ` rebasing Miles Bader
  2010-01-28 14:28     ` rebasing David Engster
@ 2010-01-28 14:53     ` Stephen J. Turnbull
  1 sibling, 0 replies; 13+ messages in thread
From: Stephen J. Turnbull @ 2010-01-28 14:53 UTC (permalink / raw)
  To: Miles Bader; +Cc: Karl Fogel, emacs-devel

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28 13:57   ` rebasing Miles Bader
  2010-01-28 14:42     ` rebasing Óscar Fuentes
@ 2010-01-28 15:06     ` Stephen J. Turnbull
  2010-01-28 18:41     ` rebasing Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Stephen J. Turnbull @ 2010-01-28 15:06 UTC (permalink / raw)
  To: Miles Bader; +Cc: Óscar Fuentes, emacs-devel

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).





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: rebasing
  2010-01-28 13:57   ` rebasing Miles Bader
  2010-01-28 14:42     ` rebasing Óscar Fuentes
  2010-01-28 15:06     ` rebasing Stephen J. Turnbull
@ 2010-01-28 18:41     ` Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2010-01-28 18:41 UTC (permalink / raw)
  To: Miles Bader; +Cc: ofv, emacs-devel

> 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".




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebasing
  2018-12-14 12:03   ` Rebasing (was: [Emacs-diffs] feature/gnus-select 46738e3 040/218: Improve SVG documentation) Stefan Monnier
@ 2018-12-17  1:32     ` Andrew Cohen
  2018-12-17  3:43       ` Rebasing Eric Abrahamsen
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cohen @ 2018-12-17  1:32 UTC (permalink / raw)
  To: emacs-devel


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.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebasing
  2018-12-17  1:32     ` Rebasing Andrew Cohen
@ 2018-12-17  3:43       ` Eric Abrahamsen
  0 siblings, 0 replies; 13+ messages in thread
From: Eric Abrahamsen @ 2018-12-17  3:43 UTC (permalink / raw)
  To: Andrew Cohen; +Cc: emacs-devel

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!



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-12-17  3:43 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-28  1:53 rebasing Miles Bader
2010-01-28  2:54 ` rebasing Stefan Monnier
2010-01-28  5:08 ` rebasing Karl Fogel
2010-01-28 13:59   ` rebasing Miles Bader
2010-01-28 14:28     ` rebasing David Engster
2010-01-28 14:53     ` rebasing Stephen J. Turnbull
2010-01-28 11:33 ` rebasing Óscar Fuentes
2010-01-28 13:57   ` rebasing Miles Bader
2010-01-28 14:42     ` rebasing Óscar Fuentes
2010-01-28 15:06     ` rebasing Stephen J. Turnbull
2010-01-28 18:41     ` rebasing Eli Zaretskii
     [not found] <20181214083441.4064.68736@vcs0.savannah.gnu.org>
     [not found] ` <20181214083451.EC1C820538@vcs0.savannah.gnu.org>
2018-12-14 12:03   ` Rebasing (was: [Emacs-diffs] feature/gnus-select 46738e3 040/218: Improve SVG documentation) Stefan Monnier
2018-12-17  1:32     ` Rebasing Andrew Cohen
2018-12-17  3:43       ` Rebasing Eric Abrahamsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).