Re: rebasing

["Óscar Fuentes" <ofv@wanadoo.es>]

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.