Re: [ELPA-diffs] /srv/bzr/emacs/elpa r374: company: Release 0.6.2

[Dmitry Gutov]

On 30.03.2013 21:12, Stefan Monnier wrote:
> > My achievement so far:
>
> > C:\Users\gutov\vc\emacs-bzr\elpa\packages\company>bzr merge
> > git://github.com/company-mode/company-mode.git
> > bzr: ERROR: exceptions.AssertionError: Invalid sha for <Commit
> > 6aea960adb30c66faa14e4bd57a4e62e94eacd94>:
> > 2a59ce05bd0a86db1911f07adb942f10b8540614
>
> In my experience bzr-git works significantly better on a local branch, so
> I always first make a local Git clone.  More specifically I normally do:
>
>     git clone <giturl>   # Done because bzr-git works better locally
>     bzr branch <localgit> tmp
>     cd tmp
>     bzr mkdir .newroot
>     bzr mv * .newroot/
>     ... maybe other bzr mv .<blabla> .newroot/ ...
>     bzr split .newroot
>     mv .newroot .../elpa/packages/<package>
>     cd .../elpa/packages/
>     bzr join <package>
>
> the "bzr mv+bzr split" dance is necessary to work around a limitation of
> bzr-git where all the root directories have the same "id", so the first
> "bzr join" worked (tho it introduced the all too famous commit that then
> triggers a bug in "bzr checkout"), but ever since we first need to do
> this dance that moves all the files to another root directory (hence
> with a different "id").

Thank you, I think I even understood what that sequence of commands is 
supposed to do.

> This said, I just tried it and the "bzr join" failed with "inventory
> already contains entry with id {README.md}": apparently there are more
> problems of id-collisions than the root directory.

That's weird. It breaks on files with the same name? It unlikely the 
other file has the same contents.

But suppose that went fine. Would cd elpa/packages/company && bzr merge 
git://... work after that?

> > Do you mind if, while ELPA transition to Git is still is progress, I commit
> > the latest version in the same manner as before?
>
> No, please do.  Just please try and preserve some of the info, e.g. by
> copying the "git log" or at the the revision id from which you merged.

Copying git log manually is exactly the kind of activity I'd like to 
avoid, hence the original question about merging.
Not sure I understand the alternative (two extra prepositions there), 
but if it's just pasting Git commit hash into the message, that works 
for me.

I already try to make corresponding version tags in the Git repo, 
though, so tracking which commit was merged last is not a problem.

That aside, almost all of company-mode change history is missing in 
elpa, so when the transition to Git is done, there's no reason not to 
fully re-import the directory from the upstream repo.