Re: Repairing the elpa branch

[Eli Zaretskii]

> From: Chong Yidong <address@hidden>
> Date: Mon, 14 Jan 2013 12:26:14 +0800
> Cc: address@hidden
> 
> Stefan Monnier <address@hidden> writes:
> 
> > I think capturing those merges is important.
> >
> > subsequent syncs with upstream are made more difficult if you use flat
> > commits.
> 
> I think it is a matter of picking the lesser of two evils.  Not being
> able to check out the branch at all (without a non-obvious workaround)
> seems to be much worse problem, compared with a bit of difficulty
> syncing with upstream.  Since no one else has come up with a better
> solution, maybe we should go with Glenn's.

What about the alternative of using the fast-import plugin?  The
following works for me with bzr 2.5.1 and 2.6b1:

  bzr fast-export elpa elpa.fi
  bzr init elpa2
  bzr fast-import elpa.fi elpa2

After this, the new elpa2 branch is healthy: I can clone it without
triggering the crash.  It can be pushed to Savannah, I think.

(For some reason, the above doesn't work if the original branch 'elpa'
is inside of a shared repo, so if you have that, first make a
stand-alone branch using these commands:

  bzr co -r170 elpa DESTINATION
  cd DESTINATION
  bzr up

and make sure DESTINATION is outside of a shared repo.  Then run
fast-export on the stand-alone branch.)

The downside of this is, of course, that all the revision-ids will
change (the hash part of the revid's displayed by bzr will be
different), so users will have to abandon their current elpa checkouts
and clone a new branch, then copy their local commits to the new
branch.  But this will be the problem with "flat commits" as well, no?