Re: git-archimport

Re: git-archimport

[Kevin Geiss]

ok. I tried this:

git-archimport kevin@desertsol.com--files/scripts--base kevin@desertsol.com--files/scripts--oco

and it always complains:

Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784

I don't have any spaces or funny characters in filenames.

On Fri, Nov 11, 2005 at 10:32:12AM +1300, Martin Langhoff wrote:
> If the two branches are related, and you want the imported git
> branches to be related, do
> 
>    git-archimport arch-eduforge@catalyst.net.nz--2004/scripts
> 
> that will bring all the stuff under scripts. If there are other
> branches or projects there that aren't related or you don't  want to
> pull, do
> 
>    git-archimport arch-eduforge@catalyst.net.nz--2004/scripts--base \
>         arch-eduforge@catalyst.net.nz--2004/scripts--oco
> 
> In any case, you shoud never pass the last token (base-0). Also, if
> you have filenames with spaces or funny chars, you'll want a patch
> that I'm about to post.
> 
> If you don't mind having this discussion on git@vger, could you
> forward it there?
> 
> cheers,
> 
> 
> martin
> 
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > hello, I was trying out the git-archimport script, I have a question.
> >
> > say I have two branches in tla (in the same archive):
> >
> > scripts--base--0
> > scripts--oco--0
> >
> > and scripts--oco--0--base-0 was tagged from scripts--base--0--patch-2.
> >
> > I first tried importing only the base branch, that worked fine. then
> > I started a new directory, and tried this:
> >
> > git arch-import -v archive/scripts--base--0 archive/scripts--oco--0
> >
> > and it keeps complaning about not being able to find scripts--oco--0--
> > patch-1.  patch-1 is just a regular commit in the tla archive.
> > (patch-2 and patch-3 are merges from scripts--base)
> >
> > anyway, am I understanding the paradigm of the git-archimport script?
> > that I should expect it to be able to create a git repository for me
> > from these 2 branches?
> >
> > thanks for any info
> >
> 

Re: git-archimport

[Martin Langhoff]

On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784

Hmmm. The script uses tla itself to get the patch. What happens if you do

  tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1

In short, you must have a recent tla configured and with the archive
registered.

cheers,



martin

Re: git-archimport

[Kevin Geiss]

On Fri, Nov 11, 2005 at 11:21:12AM +1300, Martin Langhoff wrote:
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784
> 
> Hmmm. The script uses tla itself to get the patch. What happens if you do
> 
>   tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1
> 
> In short, you must have a recent tla configured and with the archive
> registered.
> 
> cheers,
> 
> 
> 
> martin

I've got tla 1.3, and the changeset seems to be there:

10:15pm0raven>tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1                                         /tmp
usage: tla get-changeset [options] revision [dir]
try get-changeset --help
10:15pm1raven>tla get-changeset  kevin@desertsol.com--files/scripts--oco--0--patch-1                                           /tmp
gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1
gpg: Good signature from "Kevin Geiss <kevin@desertsol.com>"
10:15pm0raven>tla get-changeset --help                                                                                         /tmp
retrieve a changeset from an archive
usage: tla get-changeset [options] revision [dir]

  -h, --help     Display a help message and exit.
  -H             Display a verbose help message and exit.
  -V, --version  Display a release identifier string
                 and exit.
  -A, --archive  Override `my-default-archive'

10:16pm0raven>tla --version                                                                                                    /tmp
tla lord@emf.net--gnu-arch-2004/dists--tla--1.3--version-0(configs/gnu/This-release) from regexps.com

Re: git-archimport

[Martin Langhoff]

On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1

I've never imported a signed changeset, perhaps that's the problem. Is
the repo public so I can test it myself?

cheers,

martin

Re: git-archimport

[Kevin Geiss]

it's not really public, perhaps I can make it public though. can a tla mirror
be served over http? or does it require ssh?

I'm confident the gpg signatures aren't the problem. I imported some branches
yesterday which were all signed, they worked fine.

I suspuect the problem is that after tagging the oco branch from the base
branch, there are several places where I replayed some patches from one of the
branches to the other. some patches were skipped, some were replayed.  there
was definitely a lot of hard core cherry picking going on, in both directions.
do you think that would cause a problem?

the branches I've imported successfully were things where I had version 1, then
tagged that to create version 2, then tagged that to create version 3, with no
replay or merging going on between the branches. (everything was gpg signed
though)

On Fri, Nov 11, 2005 at 06:58:34PM +1300, Martin Langhoff wrote:
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1
> 
> I've never imported a signed changeset, perhaps that's the problem. Is
> the repo public so I can test it myself?
> 
> cheers,
> 
> martin
> 

Re: git-archimport

[Martin Langhoff]

On 11/12/05, Kevin Geiss <kevin@desertsol.com> wrote:
> it's not really public, perhaps I can make it public though. can a tla mirror
> be served over http? or does it require ssh?

It can be served over http, though the repo needs to be setup with
some special options. You can easily setup a mirror that works over
http, though I can't remember the exact options.

> I'm confident the gpg signatures aren't the problem. I imported some branches
> yesterday which were all signed, they worked fine.

Cool. That's good to know...

> I suspuect the problem is that after tagging the oco branch from the base
> branch, there are several places where I replayed some patches from one of the
> branches to the other. some patches were skipped, some were replayed.  there
> was definitely a lot of hard core cherry picking going on, in both directions.
> do you think that would cause a problem?

The archimport script was written and tested against the branches I
maintained in Arch, which had a reasonably rich and messy scheme of
branching, cherry picking and replaying of patches. We just imported
some additional branches from an unrelated project and it worked
pretty well. So cherry picking/replaying itself should not be an
issue.

On the other hand, some versions of tla are notoriously sloppy in the
patchsets they generate, forgetting to add files or adding them in two
consecutive patchsets. I don't think archimport is too tolerant, and I
did find some particular patchsets that wouldn't work correctly.

I'm interested in patches that make the import more resilient, though.
So if you can fixup archimport so your import works, and the patch is
sane, I'll vouch for its inclusion.

cheers,



martin

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?

[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

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?

[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?

[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
>
>

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/