← Back to team overview

dolfin team mailing list archive

Re: Pushing removed revisions

 

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


Follow ups

References