dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

I dont know which git crowd you talk about :) When I worked with git, I
used git-svn, and rebasing was necessity to linearize the history such that
svn could represent it.

Rebasing is _not_ the combining of two commits into one, that is called
squashing in git. I used to do that often, but always _before_ pushing to
somewhere else, and _never_ once my commits left my personal repos. The
reason is that you will mess up any merge with others if you rewrite the
commits that I have already pulled and continued working on top of.

Rebasing only changes the ordering and not the contents of the commits.
Because bzr creates commits for each merge (git does not if it is not
needed), the equivalent of git rebasing will probably behave slightly
different with bzr. I have not looked into that, so I cant say more.

Basically these concepts will be slightly different between git and bzr, so
never take a sentence about git and apply it to bzr. Not only do the words
mean different things, but the reasons for doing things one way in git may
not be valid with bzr because of the different feature set.

Martin



On 6 December 2012 12:25, Anders Logg <logg@xxxxxxxxx> wrote:

> So what's all this talk I hear from the git crowd? When they describe
> how much better git is compared to bzr, I hear 'rebase' in every other
> sentence. :-)
>
> --
> Anders
>
>
> On Thu, Dec 06, 2012 at 11:06:04AM +0100, Martin Sandve Alnæs wrote:
> >    Rewriting history that has already been pushed to others is an
> >    extremely bad idea. While reordering of alreadly pushed commits can be
> >    annoying, rewriting of already pushed commits is guaranteed to do some
> >    serious damage. Rewrite at will the commits you have not pushed yet,
> >    and nobody will even notice, but do not touch what others have got in
> >    their repositories.
> >    Martin
> >
> >    On 6 December 2012 10:50, Anders Logg <[1]logg@xxxxxxxxx> wrote:
> >
> >    On Thu, Dec 06, 2012 at 10:41:04AM +0100, Anders Logg wrote:
> >    > On Thu, Dec 06, 2012 at 09:26:09AM +0000, Garth N. Wells wrote:
> >    > > On Thu, Dec 6, 2012 at 9:20 AM, Anders Logg <[2]logg@xxxxxxxxx>
> >    wrote:
> >    > > > bzr branch lp:dolfin clean
> >    > > > cd clean
> >    > > > bzr merge ../<path-to-complexly-merged-branch>
> >    > > > bzr commit
> >    > > > bzr push lp:dolfin
> >    > > >
> >    > >
> >    > > The 'clean' branch is not necessarily  clean, which then requires
> >    > > branching lp:dolfin, which is huge.
> >    >
> >    > How can it not be clean? If you already have a 'clean' branch, then
> >    >
> >    >   rm -r clean
> >    >   bzr branch lp:dolfin clean # takes ~5 seconds if you've use
> >    init-repo
> >    >
> >    > I don't see how this branch can be anything else than clean.
> >
> >      Related to this merging back and forth, could we use rebasing to get
> >      a
> >      cleaner history? The above suggested workflow (necessary to avoid
> >      removed revisions and confuse the buildbot) often results in
> >      histories
> >      and commit messages like this:
> >      revno: 7181 [merge]
> >      committer: Anders Logg <logg@glaurung>
> >      branch nick: trunk
> >      timestamp: Wed 2012-12-05 11:48:47 +0100
> >      message:
> >        merge:
> >          Anders Logg 2012-12-05 Minor formatting fix
> >      modified:
> >        dolfin/nls/PETScSNESSolver.cpp
> >          ------------------------------------------------------------
> >          revno: 7167.1.3
> >          committer: Anders Logg <logg@glaurung>
> >          branch nick: trunk-logg
> >          timestamp: Wed 2012-12-05 11:42:27 +0100
> >          message:
> >            Minor formatting fix
> >          modified:
> >            dolfin/nls/PETScSNESSolver.cpp
> >      So a small fix was made in a file, then that could not be pushed
> >      directly to trunk but had to be merged in. So we get two changesets
> >      instead of one for a small fix which seems silly and is hard to
> >      follow.
> >      Rebasing support is included in the bzr-rewrite package, but using
> >      it might be in total conflict with the append_revisions_only
> >      flag.
> >      Whatever method we settle on, I think the motives should be:
> >      1. simple and flexible workflow (is cumbersome at the moment)
> >      2. working buildbot (possibly after hacking the buildbot script)
> >
> > Referenser
> >
> >    1. mailto:logg@xxxxxxxxx
> >    2. mailto:logg@xxxxxxxxx
>