RFD: git-bzr: anyone interested?

RFD: git-bzr: anyone interested?

[Gabriel Filion]

Hello,

I started collaborating on a script on github that tries to bring
bidirectional integration of git with Bazaar repositories. It is the
script originally written in ruby by Pieter de Bie and converted to a
shell script. You can find it here:

http://github.com/kfish/git-bzr

There is probably much left to be done to call this script functional.
Currently, it is possible to fetch revisions in a local branch, but I've
had problems with pushing revisions.

So, first things first: in order to make this thing see some substantial
progress, I will surely need help from people who are well acquainted
with git's internal plumbing, people from git-svn for their valuable
experience with extraneous vcs integration and also with people
acquainted with bzr's inner workings.

Is there any interest from people of this mailing list to see this
script make it to a usable state?
If so, having some code review would be more than good. What do you
recommend on doing: using this mailing list or putting one up that would
be specific to the project?

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Sverre Rabbelier]

Heya,

On Thu, Feb 18, 2010 at 19:13, Gabriel Filion <lelutin@gmail.com> wrote:
> Is there any interest from people of this mailing list to see this
> script make it to a usable state?

While I have no interest in bzr, I do have interest in making git
interop with more (d)vcs-es. In that light it'd be awesome if instead
you created a remote helper instead of 'git-bzr'. By implementing a
remote helper people can just clone a bzr url, and work with it in the
exact same way that they would interact with a regular git repository.
If you're interested have a look at
Documentation/git-remote-helpers.txt, and read the mailing list
archives on the subject.

> If so, having some code review would be more than good. What do you
> recommend on doing: using this mailing list or putting one up that would
> be specific to the project?

Definitely use the git list if you intend do have it included in
git.git, which I think would be a good thing :).

-- 
Cheers,

Sverre Rabbelier

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

On 2010-02-18 13:37, Sverre Rabbelier wrote:
> By implementing a
> remote helper people can just clone a bzr url, and work with it in the
> exact same way that they would interact with a regular git repository.

This sounds great, it's exactly what I'm hoping to achieve with this
project.

> If you're interested have a look at
> Documentation/git-remote-helpers.txt, and read the mailing list
> archives on the subject.
> 

The Documentation/git-remote-helpers.txt file wasn't really of much help
.. It really only barely scratches the subject, but it does not mention
how remote-helpers really work internally (e.g. how do they get called:
based on protocol used in URLs?)

I'm still trying to dig up information about how to actually build, test
and use a remote helper. I'll probably be reading code for examples.

Another detail hit me: external interaction in git seems like it's
almost always using librairies. If I'm not mistaken, bzr does not have a
separate library. So to have access to it's API, you need bzr to be
installed. This is why the current git-bzr script is using bzr +
bzr-fastimport plugin to do the job.
Is it normal / acceptable for a remote helper to have such dependancies?

And for the language used, maybe python could be logical if I can bind
directly to Bazaar's API. Tell me what you think about this.

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Sverre Rabbelier]

Heya,

[please do not cull the cc list, it is considered rude on this list]

On Fri, Feb 19, 2010 at 08:05, Gabriel Filion <lelutin@gmail.com> wrote:
> On 2010-02-18 13:37, Sverre Rabbelier wrote:
>> If you're interested have a look at
>> Documentation/git-remote-helpers.txt, and read the mailing list
>> archives on the subject.
>
> The Documentation/git-remote-helpers.txt file wasn't really of much help
> .. It really only barely scratches the subject, but it does not mention
> how remote-helpers really work internally (e.g. how do they get called:
> based on protocol used in URLs?)

True, I hope to document that better when I submit my git-remote-hg
implementation.

> I'm still trying to dig up information about how to actually build, test
> and use a remote helper. I'll probably be reading code for examples.

Perhaps you could benefit from looking at my git-remote-hg code so
far, I'll put it up on github [0] today as 'remote-hg'. If you're too
soon you'll see commit 21215675c as the head, which isn't that useful,
in that case just look again later :P.

> Another detail hit me: external interaction in git seems like it's
> almost always using librairies. If I'm not mistaken, bzr does not have a
> separate library. So to have access to it's API, you need bzr to be
> installed. This is why the current git-bzr script is using bzr +
> bzr-fastimport plugin to do the job.

That is part of the reason why the remote-helpers are implemented as
separate programs, so that whatever backend they interact with does
not become a dependency of git itself.

> Is it normal / acceptable for a remote helper to have such dependancies?

Yes, git-remote-hg depends on mercurial being installed.

> And for the language used, maybe python could be logical if I can bind
> directly to Bazaar's API. Tell me what you think about this.

Yup, that would make sense, you could put your code in
/git_remote_helpers/bzr/, alongside with the to-be-added
/git_remote_helpers/hg and /git_remote_helpers/cvs.

[0] http://github.com/SRabbelier/git

-- 
Cheers,

Sverre Rabbelier

Re: RFD: git-bzr: anyone interested?

[Gabriel]

Sverre Rabbelier writes:
> > I'm still trying to dig up information about how to actually build, test
> > and use a remote helper. I'll probably be reading code for examples.
> 
> Perhaps you could benefit from looking at my git-remote-hg code so
> far, I'll put it up on github [0] today as 'remote-hg'. If you're too
> soon you'll see commit 21215675c as the head, which isn't that useful,
> in that case just look again later :P.
> 
> [0] http://github.com/SRabbelier/git

FWIW, I'm interested in that remote-vcs code, but never figured out where it
was published. TIA for pushing it.
I'll be using it to better integrate fast-import based backup scripts.

Re: RFD: git-bzr: anyone interested?

[Sverre Rabbelier]

Heya,

On Fri, Feb 19, 2010 at 13:52, Gabriel <g2p.code@gmail.com> wrote:
> FWIW, I'm interested in that remote-vcs code, but never figured out where it
> was published. TIA for pushing it.

The remote-helpers code is already in git.git, and has been since git
1.6.6 with some improvements now in 1.7.0.

> I'll be using it to better integrate fast-import based backup scripts.

Do you mean that you'll write a remote helper to import your backups?
If so then my code could be useful as a demonstration on how to hook
up a fast-import stream.

-- 
Cheers,

Sverre Rabbelier

Re: RFD: git-bzr: anyone interested?

[Ilari Liusvaara]

On Fri, Feb 19, 2010 at 02:05:58AM -0500, Gabriel Filion wrote:
> 
> The Documentation/git-remote-helpers.txt file wasn't really of much help
> .. It really only barely scratches the subject, but it does not mention
> how remote-helpers really work internally (e.g. how do they get called:
> based on protocol used in URLs?)
> 
> I'm still trying to dig up information about how to actually build, test
> and use a remote helper. I'll probably be reading code for examples.

The remote helper is invoked with one or two parameters. 

There are five cases to consider (as rule, first argument is name of
remote [pseudo-remote in case URL was used] and the second argument is
URL to use, if any):

1) Remote <remote> without URL line but with VCS line value <helper> was used.

The called program: git-remote-<helper>  [search $PATH for it].
Number of arguements: 1
1st argument: <remote>

2) Remote <remote> with URL using <helper>::<string> syntax was used.

The called program: git-remote-<helper>  [search $PATH for it].
Number of arguments: 2
1st argument: <remote>
2st argument: <string>

3) Remote <remote> with URL using <helper>://<rest-of-URL> syntax was used.

The called program: git-remote-<helper>  [serch $PATH for it].
Number of arguments: 2
1st argument: <remote>
2st argument: <helper>://<rest-of-URL>

4) URL using <helper>::<string> syntax was used directly on command line.

The called program: git-remote-<helper>  [serch $PATH for it].
Number of arguments: 2
1st argument: <helper>::<string>
2st argument: <string>

5) URL using <helper>://<rest-of-URL> syntax was used directly on command
line.

The called program: git-remote-<helper>  [serch $PATH for it].
Number of arguments: 2
1st argument: <helper>://<rest-of-URL>
2st argument: <helper>://<rest-of-URL>


Notes:

- For 2) and 4), the helper name can only contain alphanumeric characters
  0-9, A-Z and a-z.
- For 3) and 5), the helper name can't be any of builtin protocols:
  'rsync', 'file', 'git', 'ssh', 'git+ssh' nor 'ssh+git'.
- <helper>::<string> is the strongest, followed by VCS line,
  <helper>:://<rest-of-URL> is weakest.

-Ilari

Writing git remote helpers

[Gabriel]

Sverre Rabbelier:
> Heya,
> 
> On Fri, Feb 19, 2010 at 13:52, Gabriel <g2p.code@gmail.com> wrote:
> > FWIW, I'm interested in that remote-vcs code, but never figured out
> > where it was published. TIA for pushing it.
> 
> The remote-helpers code is already in git.git, and has been since git
> 1.6.6 with some improvements now in 1.7.0.

Yes, good; I meant I haven't found example uses of that code. I'm aware
of work on a cvs helper and an hg helper. Users of the python library
would be extra convenient.

> > I'll be using it to better integrate fast-import based backup
> > scripts.
> 
> Do you mean that you'll write a remote helper to import your backups?
> If so then my code could be useful as a demonstration on how to hook
> up a fast-import stream.

I think so.

I'm using fast-import to break down a big json file into a tree, and
slurp the tree into git. I'm doing this read only. This gives me a
history of the file, compact, human-readable with git log, with an
incremental remote mirror.

I expect making it work with remote-helpers (I'll need to rebuild json
from the git input to also handle push, I don't know what else is
required) will give me convenient push-pull semantics and I'll be able
to sync that file across machines, taking advantage of git's merging
abilities.
I imagine this kind of sync use case would also work with something
like CouchDB or MongoDB, but git has a low barrier to entry for me, and
I'm not sure how well the others handle tree merging, that sometimes
requires human intervention, in a multi-master replication setup.

Speaking of remote-helpers requirements, besides the fast-import
stream, what else do I need? I imagine I'll do some book-keeping to
note when the current import was last modified (and avoid reimporting
it when unchanged), and the last hash that was pushed (and avoid
re-exporting it needlessly).

When pushing, how do I tell that the current push is a non
fast-forward? I can look for the hash of the json file in the history
of the pushed branch; if it isn't there I'll refuse the push. Do I keep
json hashes in log messages like git-svn does?
Or do I store a commit_id -> json hash mapping next to the json file?
Do I use git notes for that mapping? How do I index back from json hash
to matching commit to commits having the matching commit in their
ancestry?

When pulling, how do I tell there's nothing further to import? Same
approach as for push: look for the json hash in the history or in a
local mapping, import nothing if found?

Thinking about it some more, those two operations need a json_hash ->
commit_id lookup followed by a commit_id, commit_id -> bool DAG ancestry
test. Is that something the support library provides, or would welcome?

Re: RFD: git-bzr: anyone interested?

[Felipe Contreras]

On Thu, Feb 18, 2010 at 8:13 PM, Gabriel Filion <lelutin@gmail.com> wrote:
> Hello,
>
> I started collaborating on a script on github that tries to bring
> bidirectional integration of git with Bazaar repositories. It is the
> script originally written in ruby by Pieter de Bie and converted to a
> shell script. You can find it here:
>
> http://github.com/kfish/git-bzr
>
> There is probably much left to be done to call this script functional.
> Currently, it is possible to fetch revisions in a local branch, but I've
> had problems with pushing revisions.
>
> So, first things first: in order to make this thing see some substantial
> progress, I will surely need help from people who are well acquainted
> with git's internal plumbing, people from git-svn for their valuable
> experience with extraneous vcs integration and also with people
> acquainted with bzr's inner workings.
>
> Is there any interest from people of this mailing list to see this
> script make it to a usable state?
> If so, having some code review would be more than good. What do you
> recommend on doing: using this mailing list or putting one up that would
> be specific to the project?

I'm interested in a tool that's fast (uses git fast-import). Is that planned?

-- 
Felipe Contreras

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

On 2010-02-20 08:58, Felipe Contreras wrote:
> On Thu, Feb 18, 2010 at 8:13 PM, Gabriel Filion <lelutin@gmail.com> wrote:
>> Hello,
>>
>> I started collaborating on a script on github that tries to bring
>> bidirectional integration of git with Bazaar repositories. It is the
>> script originally written in ruby by Pieter de Bie and converted to a
>> shell script. You can find it here:
>>
>> http://github.com/kfish/git-bzr
>>
>> There is probably much left to be done to call this script functional.
>> Currently, it is possible to fetch revisions in a local branch, but I've
>> had problems with pushing revisions.
>>
>> So, first things first: in order to make this thing see some substantial
>> progress, I will surely need help from people who are well acquainted
>> with git's internal plumbing, people from git-svn for their valuable
>> experience with extraneous vcs integration and also with people
>> acquainted with bzr's inner workings.
>>
>> Is there any interest from people of this mailing list to see this
>> script make it to a usable state?
>> If so, having some code review would be more than good. What do you
>> recommend on doing: using this mailing list or putting one up that would
>> be specific to the project?
> 
> I'm interested in a tool that's fast (uses git fast-import). Is that planned?
> 
I would like to have as much, but in the context of Bazaar interaction,
I'm afraid the performance bottleneck will be actually invoking bzr (for
now, supposing this is the only way to do things). I'll start work on a
bzr remote helper shortly and will post a url to my github repos. If you
want to help in developing the remote helper and later optimizing its
performance, I'll be more than happy about it.

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

On 2010-02-19 08:55, Ilari Liusvaara wrote:
> On Fri, Feb 19, 2010 at 02:05:58AM -0500, Gabriel Filion wrote:
>>
>> The Documentation/git-remote-helpers.txt file wasn't really of much help
>> .. It really only barely scratches the subject, but it does not mention
>> how remote-helpers really work internally (e.g. how do they get called:
>> based on protocol used in URLs?)
>>
>> I'm still trying to dig up information about how to actually build, test
>> and use a remote helper. I'll probably be reading code for examples.
> 
> The remote helper is invoked with one or two parameters. 
> 
> There are five cases to consider (as rule, first argument is name of
> remote [pseudo-remote in case URL was used] and the second argument is
> URL to use, if any):
> 
> 1) Remote <remote> without URL line but with VCS line value <helper> was used.
> 
> The called program: git-remote-<helper>  [search $PATH for it].
> Number of arguements: 1
> 1st argument: <remote>
> 
> 2) Remote <remote> with URL using <helper>::<string> syntax was used.
> 
> The called program: git-remote-<helper>  [search $PATH for it].
> Number of arguments: 2
> 1st argument: <remote>
> 2st argument: <string>
> 
> 3) Remote <remote> with URL using <helper>://<rest-of-URL> syntax was used.
> 
> The called program: git-remote-<helper>  [serch $PATH for it].
> Number of arguments: 2
> 1st argument: <remote>
> 2st argument: <helper>://<rest-of-URL>
> 
> 4) URL using <helper>::<string> syntax was used directly on command line.
> 
> The called program: git-remote-<helper>  [serch $PATH for it].
> Number of arguments: 2
> 1st argument: <helper>::<string>
> 2st argument: <string>
> 
> 5) URL using <helper>://<rest-of-URL> syntax was used directly on command
> line.
> 
> The called program: git-remote-<helper>  [serch $PATH for it].
> Number of arguments: 2
> 1st argument: <helper>://<rest-of-URL>
> 2st argument: <helper>://<rest-of-URL>
> 
> 
> Notes:
> 
> - For 2) and 4), the helper name can only contain alphanumeric characters
>   0-9, A-Z and a-z.
> - For 3) and 5), the helper name can't be any of builtin protocols:
>   'rsync', 'file', 'git', 'ssh', 'git+ssh' nor 'ssh+git'.
> - <helper>::<string> is the strongest, followed by VCS line,
>   <helper>:://<rest-of-URL> is weakest.
> 

This will prove quite useful! This summary should be inspired upon to
add details about how remote helpers are called in the documentation.

I created a dummy remote helper script to test how things are called. I
was successful in having a remote created with URL
bzr://some.server/path to be handed down to the script git-remote-bzr.

However, when I tried creating a git-remote-bzr+ssh link pointing to the
git-remote-bzr script so that URLs like bzr+ssh://something/somewhere
(this is how ssh is used with Bazaar) got handed down to the dummy
script, it kept saying the "bzr+ssh" protocol wasn't handled. So, it
would seem I can't have special characters in the helper script name.

How could I get this protocol to be handled by the remote helper? Having
to type bzr::bzr+ssh://something/somewhere looks like a really awkward
thing to write. Also, requiring users to add something to a protocol
that already identifies the type of remote repository (and, that is
already well known and used by users of bzr) is not interesting in a
usability point of view.

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

On 2010-02-19 02:49, Sverre Rabbelier wrote:
> Heya,
> 
> [please do not cull the cc list, it is considered rude on this list]
> 
Oh .. sorry for that. I will keep this in mind from now on.

> Perhaps you could benefit from looking at my git-remote-hg code so
> far, I'll put it up on github [0] today as 'remote-hg'.
> [...]
> Yup, that would make sense, you could put your code in
> /git_remote_helpers/bzr/, alongside with the to-be-added
> /git_remote_helpers/hg and /git_remote_helpers/cvs.
> 
> [0] http://github.com/SRabbelier/git
> 
Thanks. I'm sure it'll be helpful.

I'm probably not going to push anything in the short future, cause I'd
like to experiment a bit and think things through before starting to
code. But the bzr remote helper code should be in my git clone on
github. This way interested people can follow along and comment on the
progress (more discussions will come on this list)

http://github.com/lelutin/git

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Ilari Liusvaara]

On Sun, Feb 21, 2010 at 11:42:54PM -0500, Gabriel Filion wrote:
> On 2010-02-19 08:55, Ilari Liusvaara wrote:
 
> However, when I tried creating a git-remote-bzr+ssh link pointing to the
> git-remote-bzr script so that URLs like bzr+ssh://something/somewhere
> (this is how ssh is used with Bazaar) got handed down to the dummy
> script, it kept saying the "bzr+ssh" protocol wasn't handled. So, it
> would seem I can't have special characters in the helper script name.

Yeah, it seems like remote helper names can't have non-alphanum characters
(oops).

> How could I get this protocol to be handled by the remote helper? Having
> to type bzr::bzr+ssh://something/somewhere looks like a really awkward
> thing to write. Also, requiring users to add something to a protocol
> that already identifies the type of remote repository (and, that is
> already well known and used by users of bzr) is not interesting in a
> usability point of view.

bzr::ssh://something/somewhere ?

That goes to git-remote-bzr (as 'ssh://something/somewhere').

-Ilari

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

On 2010-02-22 05:51, Ilari Liusvaara wrote:
> bzr::ssh://something/somewhere ?
> 
> That goes to git-remote-bzr (as 'ssh://something/somewhere').
> 
That would be feasible. But for users, when they copy URLs from sites,
they'd probably like to use it as is. (I'd like it to be like that :P )

But, as long as it's not possible right now to use "+" in the URL, I can
implement it exactly like you said and maybe change it later if helper
names obtain the right to have non-alnum characters.

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Ilari Liusvaara]

On Mon, Feb 22, 2010 at 10:20:41PM -0500, Gabriel Filion wrote:
> On 2010-02-22 05:51, Ilari Liusvaara wrote:
> > bzr::ssh://something/somewhere ?
> > 
> > That goes to git-remote-bzr (as 'ssh://something/somewhere').
> > 
> That would be feasible. But for users, when they copy URLs from sites,
> they'd probably like to use it as is. (I'd like it to be like that :P )
> 
> But, as long as it's not possible right now to use "+" in the URL, I can
> implement it exactly like you said and maybe change it later if helper
> names obtain the right to have non-alnum characters.

Patch to allow '+', '-' and '.' sent (those characters were taken from
IETF STD66).

Its entierely possible to have remote helpers set up so that in git
version that doesn't allow '+', the following work (passed as means
beginning of second (URL) argument):

1) 'bzr://' [passed as 'bzr://']
2) 'bzr::ssh://' [passed as 'ssh://']

And in versions that allow '+', the following additionally work:

3) 'bzr+ssh://' [passed as 'bzr+ssh://']
4) 'ssh+bzr://' [passed as 'ssh+bzr://']

That can be done by making three copies of executable ('git-remote-bzr',
'git-remote-bzr+ssh' and 'git-remote-ssh+bzr') and the infering correct
protocol from prefix of 2nd arguement (see those "passed as" strings).

-Ilari

Re: RFD: git-bzr: anyone interested?

[Chris Packham]

Hi,

How far did git-bzr or git-remote-bzr get?

I've tried git-bzr from the repo and I seem to be stumbling on bzr not
having the fast-export command after I install the fast-import plugin
as per [1]. So I think its a bazzar problem not a git-bzr one. Has
anyone got a fully worked example including the installation of the
required bits and pieces.

Alternatively what I'm really trying to do is update a series of
patches for an upstream project that is managed with bazzar. We have
30 or so patches with our customizations so I'd like to get git (or
bzr) to do the heavy lifting for me. In git I'd do something like this

git clone <upstream>
git checkout <tag that corresponds to the version of the tarball we use>
git checkout -b our-patches
git am <patches>
git rebase <tag that corresponds to the new version we want to use>
git format-patch ...

Anybody got a similar recipe for bzr? (yes I'll go ask on the bzr list too)

[1] http://github.com/kfish/git-bzr/blob/master/README

Re: RFD: git-bzr: anyone interested?

[Dmitrijs Ledkovs]

On 26 April 2010 22:41, Chris Packham <judge.packham@gmail.com> wrote:
> Hi,
>
> How far did git-bzr or git-remote-bzr get?
>

Don't know, never used.

As far as I know bzr-git can fetch, clone, commit and push to/from
bzr/git repos. Not sure why you would want git-bzr

> I've tried git-bzr from the repo and I seem to be stumbling on bzr not
> having the fast-export command after I install the fast-import plugin
> as per [1]. So I think its a bazzar problem not a git-bzr one. Has
> anyone got a fully worked example including the installation of the
> required bits and pieces.
>

fast-export would loose information AFAIK use bzr-git with dalwich.

> Alternatively what I'm really trying to do is update a series of
> patches for an upstream project that is managed with bazzar. We have
> 30 or so patches with our customizations so I'd like to get git (or
> bzr) to do the heavy lifting for me. In git I'd do something like this
>
> git clone <upstream>
bzr branch <upstream>
> git checkout <tag that corresponds to the version of the tarball we use>
bzr checkout -rtag:<tagname> tag-branch
> git checkout -b our-patches
cd tag-branch
> git am <patches>
bzr patch patch1 patch2 patch2
> git rebase <tag that corresponds to the new version we want to use>
bzr rebase ../<upstream>
> git format-patch ...
>
bzr log -p; or bazaar send -p or create bundle depends on what you want.

> Anybody got a similar recipe for bzr? (yes I'll go ask on the bzr list too)
>

Although I think you really want
http://wiki.bazaar.canonical.com/BzrPipeline which helps you import
patches ontop of a branch, update upstream, update (merge) patches,
and export them again. It's something like quilt, topgit but
bzr-styled ;-)

> [1] http://github.com/kfish/git-bzr/blob/master/README

=) hope this helps.

ps. anyone can help with repo.or.cz not reusing objects from parent
when pushing to a fork? reported to admin@repo.or.cz they can
reproduce the bug but something dodgy is going on. Thanks. Me will
shut up about bzr now =)

Re: RFD: git-bzr: anyone interested?

[Chris Packham]

On Mon, Apr 26, 2010 at 4:46 PM, Dmitrijs Ledkovs
<dmitrij.ledkov@ubuntu.com> wrote:
> On 26 April 2010 22:41, Chris Packham <judge.packham@gmail.com> wrote:
>> Hi,
>>
>> How far did git-bzr or git-remote-bzr get?
>>
>
> Don't know, never used.
>
> As far as I know bzr-git can fetch, clone, commit and push to/from
> bzr/git repos. Not sure why you would want git-bzr

Because I searched the git list and thats what I found. Also because
I'm familiar with what I want to do using git.

>> I've tried git-bzr from the repo and I seem to be stumbling on bzr not
>> having the fast-export command after I install the fast-import plugin
>> as per [1]. So I think its a bazzar problem not a git-bzr one. Has
>> anyone got a fully worked example including the installation of the
>> required bits and pieces.
>>
>
> fast-export would loose information AFAIK use bzr-git with dalwich.
>

I'm not really worried about information loss. As long as I can still
get at the tags I'm happy. I'm not really planning on keeping this
repository after migrating the patches (well may be I'll keep it
around to submit the changes but I don't think the upstream project
would find them interesting anyway).

>> Alternatively what I'm really trying to do is update a series of
>> patches for an upstream project that is managed with bazzar. We have
>> 30 or so patches with our customizations so I'd like to get git (or
>> bzr) to do the heavy lifting for me. In git I'd do something like this
>>
>> git clone <upstream>
> bzr branch <upstream>
>> git checkout <tag that corresponds to the version of the tarball we use>
> bzr checkout -rtag:<tagname> tag-branch
>> git checkout -b our-patches
> cd tag-branch
>> git am <patches>
> bzr patch patch1 patch2 patch2
>> git rebase <tag that corresponds to the new version we want to use>
> bzr rebase ../<upstream>
>> git format-patch ...
>>
> bzr log -p; or bazaar send -p or create bundle depends on what you want.
>

OK heres where I run into problems which I think may be due to
openSUSE 11.2s really old version of bzr (1.17). I was missing a 'cd'
in my example so I'm not sure if there is an implied one in the bzr
example. Either way its barfing on 'bzr checkout -rtag:<tagname>
tag-branch' and either refuses to work saying that tag-branch is not a
branch or crashes with I omit tag-branch.

>> Anybody got a similar recipe for bzr? (yes I'll go ask on the bzr list too)
>>

except the list is subscriber only :( .

> Although I think you really want
> http://wiki.bazaar.canonical.com/BzrPipeline which helps you import
> patches ontop of a branch, update upstream, update (merge) patches,
> and export them again. It's something like quilt, topgit but
> bzr-styled ;-)

I'll give it a whirl when I've installed a newer version.

> Thanks. Me will shut up about bzr now =)
>

Yeah me too. I should probably bite the bullet and subscribe or import
the old and new tarballs and see what git can do with limited
information.

Re: RFD: git-bzr: anyone interested?

[Miles Bader]

Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com> writes:
> As far as I know bzr-git can fetch, clone, commit and push to/from
> bzr/git repos. Not sure why you would want git-bzr

In general people want this because they prefer the
UI/functionality/speed/etc of the git client over that of the bzr
client, but also want to interact with a project that uses a bzr repo.

So, something like git-bzr is necessary for this (though
"git-remote-bzr" is sounding like it will be the future).

Thanks,

-Miles

-- 
We have met the enemy, and he is us.  -- Pogo

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

Hello,

On 2010-04-26 17:41, Chris Packham wrote:
> How far did git-bzr or git-remote-bzr get?
> 

I unfortunately haven't had much time to fiddle with this. Having a full
time job doesn't give me much space for experiences :( And on my free
time, I've been a bit busy with one of my projects..


I've tried simply "plugging in" the bzr-fastimport plugin to do the
communication part. They already implement output similar to what
git-fastimport expects. I was stuck on the part where you have to
specify "marks" files, and about where to place them, so I left it there
for now.

I'll try and work on this pretty soon, but since I'm doing this on spare
time, any help would be welcome. Maybe the good thing to do would be to
put up a page somewhere with a mini-roadmap and the info needed/the info
that was found out?
By using bzr fast-import, the whole thing shouldn't take too long.

> I've tried git-bzr from the repo and I seem to be stumbling on bzr not
> having the fast-export command after I install the fast-import plugin
> as per [1].

> [1] http://github.com/kfish/git-bzr/blob/master/README

This script needs you to install bazaar and the bzr "fast-import"
plugin. Normally the fast-export command is implemented by it. You need
a rather up-to-date version, though.
I've found this script to work mostly for pulling in changes from bzr
into git. Pushing has proven to be from slow to non-functional.


As for the interest in this: mine is in using only one tool to do the
work right and not having to switch from using 3 vcs tools (the current
situation at work is 2 -- git and svn -- but soon bzr will come in). And
for the one tool, I'd like to choose git.
stupid reason? probably. but I've tried bzr and I don't like it.

-- 
Gabriel Filion

Re: RFD: git-bzr: anyone interested?

[Dmitrijs Ledkovs]

On 27 April 2010 03:53, Gabriel Filion <lelutin@gmail.com> wrote:
> Hello,
>
> On 2010-04-26 17:41, Chris Packham wrote:
>> How far did git-bzr or git-remote-bzr get?
>>
>
> I unfortunately haven't had much time to fiddle with this. Having a full
> time job doesn't give me much space for experiences :( And on my free
> time, I've been a bit busy with one of my projects..
>
>
> I've tried simply "plugging in" the bzr-fastimport plugin to do the
> communication part. They already implement output similar to what
> git-fastimport expects. I was stuck on the part where you have to
> specify "marks" files, and about where to place them, so I left it there
> for now.
>

Except that bzr-fast-export -> bzr-fast-import will produce similar
history but all revision ids will be different so you will not be able
to merge in bzr after you worked in git =/ so it will be read-only.
Marks files are used when you want to import multiple related bzr
branches into a git repo. So in general case you will not need it =)

> I'll try and work on this pretty soon, but since I'm doing this on spare
> time, any help would be welcome. Maybe the good thing to do would be to
> put up a page somewhere with a mini-roadmap and the info needed/the info
> that was found out?
> By using bzr fast-import, the whole thing shouldn't take too long.
>
>> I've tried git-bzr from the repo and I seem to be stumbling on bzr not
>> having the fast-export command after I install the fast-import plugin
>> as per [1].
>
>> [1] http://github.com/kfish/git-bzr/blob/master/README
>
> This script needs you to install bazaar and the bzr "fast-import"
> plugin. Normally the fast-export command is implemented by it. You need
> a rather up-to-date version, though.
> I've found this script to work mostly for pulling in changes from bzr
> into git. Pushing has proven to be from slow to non-functional.
>

Well I did this:

$ mkdir -p ~/.bazaar/plugins
$ bzr branch lp:bzr-fast-import ~/.bazaar/fast-import
$ bzr branch lp:xiphos
$ git init git-xiphos
$ cd git-xiphos
$ bzr fast-export ../xiphos | git fast-import

And the resulting git repository has master branch with tags.

>
> As for the interest in this: mine is in using only one tool to do the
> work right and not having to switch from using 3 vcs tools (the current
> situation at work is 2 -- git and svn -- but soon bzr will come in). And
> for the one tool, I'd like to choose git.
> stupid reason? probably. but I've tried bzr and I don't like it.
>

Well I have my stupid reasons as well for choosing bzr for small
projects. With bzr-hg, bzr-git & bzr-svn I can work on all 4 without
doing a context switch. When I work on something big though like gcc
or binutils. Yeah git.... because of size & performance.

With bzr-* plugins though you generally get roundtrip & svn support is
excellent. On two machines bzr branch svn://URL will give identical
branches which you can merge between in bzr & svn, unlike git where
you have to use canonical import to have same SHA-1's on commits.

> --
> Gabriel Filion
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: RFD: git-bzr: anyone interested?

[Chris Packham]

On Tue, Apr 27, 2010 at 1:47 AM, Dmitrijs Ledkovs
<dmitrij.ledkov@ubuntu.com> wrote:
>
> Well I did this:
>
> $ mkdir -p ~/.bazaar/plugins
> $ bzr branch lp:bzr-fast-import ~/.bazaar/fast-import
> $ bzr branch lp:xiphos
> $ git init git-xiphos
> $ cd git-xiphos
> $ bzr fast-export ../xiphos | git fast-import

Bringing this full circle this is my version of what I needed to do.
Again its likely that the old version of bzr that openSUSE uses is the
reason the above didn't "just work(tm)" but just in case anyone else
is hitting the same problem heres my working recipbzr branch
lp:bzr-fast-import ~/.bazaar/fast-importe.

# plugin install
mkdir -p ~/.bazaar/plugins
bzr branch lp:bzr-fast-import ~/.bazaar/plugins/fastimport # note it
needs to be fastimport not fast-import or fast_import
bzr plugins --verbose  # just to check that the plugin is successfully installed

# actual import into git
bzr branch lp:upstart
git init upstart-git
cd upstart-git/
bzr fast-export ../upstart | git fast-import

> And the resulting git repository has master branch with tags.
>

Which is almost true for me except some tags weren't added due to
"missing revisions", and dang it if it doesn't happen to be the one
I'm after. This is probably because the 0.5 series for upstart is off
on its own, whatever fixes were in 0.5 probably have been merged I
just can't tell.

I think for my purposes I can manually find something close enough to
the actual revision that I need, either that or mess around trying to
import the obsolete 0.5 branch as well but thats something for me to
work through on my own now that I've got the fast-export recipe
working.

Re: RFD: git-bzr: anyone interested?

[Chris Packham]

On Mon, Apr 26, 2010 at 7:53 PM, Gabriel Filion <lelutin@gmail.com> wrote:
> Hello,
>
> On 2010-04-26 17:41, Chris Packham wrote:
>> How far did git-bzr or git-remote-bzr get?
>>
>
> I unfortunately haven't had much time to fiddle with this. Having a full
> time job doesn't give me much space for experiences :( And on my free
> time, I've been a bit busy with one of my projects..

Fair enough. My day job tends to suck up most of the time I want to
spend in front of a computer too.

> I've tried simply "plugging in" the bzr-fastimport plugin to do the
> communication part. They already implement output similar to what
> git-fastimport expects. I was stuck on the part where you have to
> specify "marks" files, and about where to place them, so I left it there
> for now.
>
> I'll try and work on this pretty soon, but since I'm doing this on spare
> time, any help would be welcome. Maybe the good thing to do would be to
> put up a page somewhere with a mini-roadmap and the info needed/the info
> that was found out?
> By using bzr fast-import, the whole thing shouldn't take too long.

I'm probably unqualified to help, not being familiar with bzr at all,
but if you want a monkey to write test cases I can probably do that.

>> [1] http://github.com/kfish/git-bzr/blob/master/README
>
> This script needs you to install bazaar and the bzr "fast-import"
> plugin. Normally the fast-export command is implemented by it. You need
> a rather up-to-date version, though.
> I've found this script to work mostly for pulling in changes from bzr
> into git. Pushing has proven to be from slow to non-functional.

Actually I can probably contribute a snippet for your README file on
how to install the required plugin if that would be helpful. It took
me some fiddling an experimentation to work it out even after reading
the bazzar documentation.

> As for the interest in this: mine is in using only one tool to do the
> work right and not having to switch from using 3 vcs tools (the current
> situation at work is 2 -- git and svn -- but soon bzr will come in). And
> for the one tool, I'd like to choose git.
> stupid reason? probably. but I've tried bzr and I don't like it.

My interest was purely around updating patches one project that we use
that happens to use bazaar. Normally most things we do are either in
git or built from tarballs + patches.

Re: RFD: git-bzr: anyone interested?

[Dmitrijs Ledkovs]

I don't know if anyone is interested:

I've did the fast-export | import with marks for all release branches
of upstart.
So I have git repo with code since 0.1 series upto the latest 1.0 series.
I've also committed an update branch which has script to import new revisions.
I might put it into my crontab for updates.... but small bash script
is there to update it.

So far it looks good to me e.g. there is nothing missing what is
present in the upstream branches.

git clone git://gitorious.org/upstart/upstart.git

Happy rebasing ;-)

Re: RFD: git-bzr: anyone interested?

[Conrad Parker]

Hi,

Anyone interested in git-bzr might also want to look at some recent
rewrites; from the current git-bzr README:

The following are rewrites in Python and may offer better bzr integration:
  * http://github.com/termie/git-bzr-ng
  * http://github.com/matthew-brett/git-bzr

(... and I'd also be interested to know how well either of these work :)

cheers,

Conrad (kfish).

On 27 April 2010 06:41, Chris Packham <judge.packham@gmail.com> wrote:
> Hi,
>
> How far did git-bzr or git-remote-bzr get?
>
> I've tried git-bzr from the repo and I seem to be stumbling on bzr not
> having the fast-export command after I install the fast-import plugin
> as per [1]. So I think its a bazzar problem not a git-bzr one. Has
> anyone got a fully worked example including the installation of the
> required bits and pieces.
>
> Alternatively what I'm really trying to do is update a series of
> patches for an upstream project that is managed with bazzar. We have
> 30 or so patches with our customizations so I'd like to get git (or
> bzr) to do the heavy lifting for me. In git I'd do something like this
>
> git clone <upstream>
> git checkout <tag that corresponds to the version of the tarball we use>
> git checkout -b our-patches
> git am <patches>
> git rebase <tag that corresponds to the new version we want to use>
> git format-patch ...
>
> Anybody got a similar recipe for bzr? (yes I'll go ask on the bzr list too)
>
> [1] http://github.com/kfish/git-bzr/blob/master/README
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: RFD: git-bzr: anyone interested?

[Miles Bader]

Conrad Parker <conrad@metadecks.org> writes:
> Anyone interested in git-bzr might also want to look at some recent
> rewrites; from the current git-bzr README:
>
> The following are rewrites in Python and may offer better bzr integration:
>   * http://github.com/termie/git-bzr-ng
>   * http://github.com/matthew-brett/git-bzr
>
> (... and I'd also be interested to know how well either of these work :)

Me too.

There are some projects I'd like to work on that have bzr repos, but
it's always very painful to use the actual bzr client...

-Miles

-- 
Christian, n. One who follows the teachings of Christ so long as they are not
inconsistent with a life of sin.

Re: RFD: git-bzr: anyone interested?

[Gabriel Filion]

(restoring CC list. it is customary on the git list to reply-all)

On 2010-08-06 23:36, Miles Bader wrote:
> Conrad Parker <conrad@metadecks.org> writes:
>> Anyone interested in git-bzr might also want to look at some recent
>> rewrites; from the current git-bzr README:
>>
>> The following are rewrites in Python and may offer better bzr integration:
>>   * http://github.com/termie/git-bzr-ng
>>   * http://github.com/matthew-brett/git-bzr
>>
>> (... and I'd also be interested to know how well either of these work :)

I've found some time to begin implementing a remote-helper[1] this week.
Plugging in a call to "bzr fast-export" made cloning a repository with
"git clone bzr::url" and pulling new revisions in with "git pull" work
with minimum effort.

[1]:http://github.com/lelutin/git-remote-bzr

However, as reported in this bug[2], the fast-import path to push
commits back to bzr is broken in the bzr plugin. Once we get this
working, we should be able to round-trip.

[2]:https://bugs.launchpad.net/bzr-fastimport/+bug/347729

Doing "git pull" currently exports all history from the Bazaar branch to
incorporate the needed commits in the git repo. This is really
suboptimal, but I thought having something that works before making it
work right would help me get some insights on the remote-helper's code.


The very cool thing about making this into a remote-helper instead of a
git command in itself, is that we won't have to redisign (and possibly
re-implement) the command line interface, since git will be calling the
remote-helper with the right commands at the appropriate time.

-- 
Gabriel Filion

git-archimport (was: Re: RFD: git-bzr: anyone interested?)

[Jakub Narebski]

Conrad Parker <conrad@metadecks.org> writes:

> Anyone interested in git-bzr might also want to look at some recent
> rewrites; from the current git-bzr README:
> 
> The following are rewrites in Python and may offer better bzr integration:
>   * http://github.com/termie/git-bzr-ng
>   * http://github.com/matthew-brett/git-bzr
> 
> (... and I'd also be interested to know how well either of these work :)
> 
> cheers,

By the way, perhaps it is time to finally retire git-archimport, or at
least move it to contrib section.  Is there anyone using it?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: git-archimport

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> Conrad Parker <conrad@metadecks.org> writes:
>
>> Anyone interested in git-bzr might also want to look at some recent
>> rewrites; from the current git-bzr README:
>> 
>> The following are rewrites in Python and may offer better bzr integration:
>>   * http://github.com/termie/git-bzr-ng
>>   * http://github.com/matthew-brett/git-bzr
>> 
>> (... and I'd also be interested to know how well either of these work :)
>> 
>> cheers,
>
> By the way, perhaps it is time to finally retire git-archimport, or at
> least move it to contrib section.  Is there anyone using it?

Definitely not using it on a daily basis, but I still have a few GNU
Arch archives on my machine, and may need to import them into Git one
day.

If git-archimport causes a problem wrt maintainance, I'd understand
that it be deprecated, but if it doesn't cost to keep it around, I
don't think it'd be a good thing to drop it.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: RFD: git-bzr: anyone interested?

[Miles Bader]

On Sat, Aug 7, 2010 at 5:48 PM, Gabriel Filion <lelutin@gmail.com> wrote:
> (restoring CC list. it is customary on the git list to reply-all)

Sorry, I was using gmane (mail/news gateway); I'm not totally sure
what it does with replies...

I'll use mail for replies in the future.

Thanks,

-Miles

-- 
Do not taunt Happy Fun Ball.