[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: [ELPA-diffs] /srv/bzr/emacs/elpa r374: company: Release 0.6.2
Date: Sat, 30 Mar 2013 21:49:41 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

On 30.03.2013 21:12, Stefan Monnier wrote:
My achievement so far:

C:\Users\gutov\vc\emacs-bzr\elpa\packages\company>bzr merge
bzr: ERROR: exceptions.AssertionError: Invalid sha for <Commit

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]