[CFH] Remotes conversion script

[CFH] Remotes conversion script

[Petr Baudis]

  Hi,

  if someone is currently bored, it would be very nice to have a
conversion script for converting remotes/ to [remote] .config sections
(unless I missed it and someone already did such a great thing).

  I think about supporting just the [remote] sections in Cogito since
they are much easier to handle than the remotes/ file format, but in
order to maintain reasonable degree of compatibility with current
repositories (even freshly cloned since git-clone still generates those
horrible things ;-) ) such a script would be a must... and since this is
not interesting strictly for Cogito only, I hoped that perhaps some core
Git people would be interested to help here.

  PS: It would be nice if Git, when writing remote records during clone,
would note "this is supposed to just cover all the remote branches".
While Git does not support it now, in cg-fetch I would like to support
automatically picking up new branches in case you cloned all the
branches initially, but I need to distinguish the case when you are
interested in just a fixed set of those. BTW, I want to also remove gone
branches, but in line with the Git paranoia I'll just move the refs to
refs/remotes/*/.attic/ and let the user shoot at will.

  Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [CFH] Remotes conversion script

[Jakub Narebski]

Petr Baudis wrote:

>   if someone is currently bored, it would be very nice to have a
> conversion script for converting remotes/ to [remote] .config sections
> (unless I missed it and someone already did such a great thing).
> 
>   I think about supporting just the [remote] sections in Cogito since
> they are much easier to handle than the remotes/ file format, but in
> order to maintain reasonable degree of compatibility with current
> repositories (even freshly cloned since git-clone still generates those
> horrible things ;-) ) such a script would be a must... and since this is
> not interesting strictly for Cogito only, I hoped that perhaps some core
> Git people would be interested to help here.

If I remember correctly currently only some functionality provided by
remotes file can be provided by [remote] and [branch] sections of git
config.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [CFH] Remotes conversion script

[Johannes Schindelin]

Hi,

On Sun, 24 Sep 2006, Petr Baudis wrote:

>   if someone is currently bored, it would be very nice to have a
> conversion script for converting remotes/ to [remote] .config sections
> (unless I missed it and someone already did such a great thing).

contrib/remotes2config.sh. Since May 3rd.

Hth,
Dscho

Re: [CFH] Remotes conversion script

[Johannes Schindelin]

Hi,

On Sun, 24 Sep 2006, Jakub Narebski wrote:

> If I remember correctly currently only some functionality provided by
> remotes file can be provided by [remote] and [branch] sections of git
> config.

... and what might the lacking functionality be?

.git/remotes/<name>    config

URL:                   remote.<name>.url
Pull:                  remote.<name>.fetch
Push:                  remote.<name>.push

You can even have multiple entries in the config, and it behaves as if you 
had multiple lines in .git/remotes/<name>.

Ciao,
Dscho

Re: [CFH] Remotes conversion script

[Petr Baudis]

Dear diary, on Sun, Sep 24, 2006 at 11:57:34PM CEST, I got a letter
where Santi <sbejar@gmail.com> said that...
> 2006/9/24, Petr Baudis <pasky@suse.cz>:
> >  I think about supporting just the [remote] sections in Cogito since
> >they are much easier to handle than the remotes/ file format,
> 
> What about branches/ files?

I don't know yet. Cogito will certainly *recognize* them for *long* time
ahead (many months to be sure), no matter what will we decide to do with
them. Of course Cogito would start being growingly critical about them.

But the best technical solution is probably to stop using remote
branches in the heads namespace in new repositories altogether and
strictly create a new [remote] per each repository you fetch from (no
matter if it's a single branch or all of them or just a set), and there
will be cg-remote-add and perhaps cg-remote-chg to help you maintain
that easily.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [CFH] Remotes conversion script

[Santi]

2006/9/25, Petr Baudis <pasky@ucw.cz>:
> Dear diary, on Sun, Sep 24, 2006 at 11:57:34PM CEST, I got a letter
> where Santi <sbejar@gmail.com> said that...
> > 2006/9/24, Petr Baudis <pasky@suse.cz>:
> > >  I think about supporting just the [remote] sections in Cogito since
> > >they are much easier to handle than the remotes/ file format,
> >
> > What about branches/ files?
>
> I don't know yet. Cogito will certainly *recognize* them for *long* time
> ahead (many months to be sure), no matter what will we decide to do with
> them. Of course Cogito would start being growingly critical about them.
>

It could be I'm wrong (for sure, I miss something), but I see the
branches/ files like [remote] sections files with just one fetch:

.git/branches/git:
git://...../git.gi

would be:

[remote "git"]
url=git://...../git.git
fetch=refs/heads/master:refs/heads/git

you could have a wrapper around repo-config to "support" only the
[remote]  sections.

  Santi

Re: [CFH] Remotes conversion script

[Petr Baudis]

Dear diary, on Mon, Sep 25, 2006 at 12:34:24AM CEST, I got a letter
where Santi <sbejar@gmail.com> said that...
> It could be I'm wrong (for sure, I miss something), but I see the
> branches/ files like [remote] sections files with just one fetch:
> 
> .git/branches/git:
> git://...../git.gi
> 
> would be:
> 
> [remote "git"]
> url=git://...../git.git
> fetch=refs/heads/master:refs/heads/git

That's basically right, the point is that with moving to remotes
support, we will make each remote live in its own separate namespace,
so when creating new remote branch, it won't live as refs/heads/git
but as refs/remotes/git/master (referencing to it as 'git' will still
work as long as you won't have a local 'git' branch, in which case
you will have to use 'remotes/git'). Cogito will certainly still have
to support using the old setup, but it will not support creating it
anymore.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [CFH] Remotes conversion script

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 24 Sep 2006, Jakub Narebski wrote:
> 
>> If I remember correctly currently only some functionality provided by
>> remotes file can be provided by [remote] and [branch] sections of git
>> config.
> 
> ... and what might the lacking functionality be?
> 
> .git/remotes/<name>    config
> 
> URL:                   remote.<name>.url
> Pull:                  remote.<name>.fetch
> Push:                  remote.<name>.push
> 
> You can even have multiple entries in the config, and it behaves as if you 
> had multiple lines in .git/remotes/<name>.

Hmmm... strange, in 'next' branch.<name>.* are documented in
Documentation/config.txt, but the remote.<name>.* are not.

Neither is documented [branch "funky name"] syntax (branch."funky name").

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [CFH] Remotes conversion script

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Mon, Sep 25, 2006 at 12:34:24AM CEST, I got a letter
> where Santi <sbejar@gmail.com> said that...
>> It could be I'm wrong (for sure, I miss something), but I see the
>> branches/ files like [remote] sections files with just one fetch:
>> 
>> .git/branches/git:
>> git://...../git.gi
>> 
>> would be:
>> 
>> [remote "git"]
>> url=git://...../git.git
>> fetch=refs/heads/master:refs/heads/git
> 
> That's basically right, the point is that with moving to remotes
> support, we will make each remote live in its own separate namespace,

Which is overkill if we fetch only from one directory. Besides using
separate remotes (hmmm, we should add support for refs/remotes/ in gitweb)
is a policy decision.

On somewhat unrelated issue: should git-clone create [remote] section
(and perhaps [branch] sections) instead of remotes file?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [CFH] Remotes conversion script

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 24 Sep 2006, Jakub Narebski wrote:
> 
>> If I remember correctly currently only some functionality provided by
>> remotes file can be provided by [remote] and [branch] sections of git
>> config.
> 
> ... and what might the lacking functionality be?

What about
        Pull: +refs/heads/pu:refs/heads/pu
functionality, i.e. allowing force-update (non fast-forward) fetches?

> .git/remotes/<name>    config
> 
> URL:                   remote.<name>.url
> Pull:                  remote.<name>.fetch
> Push:                  remote.<name>.push
> 
> You can even have multiple entries in the config, and it behaves as if you 
> had multiple lines in .git/remotes/<name>.

And first pull line is default branch to merge, all the rest is marked
as not-for-merge?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [CFH] Remotes conversion script

[Petr Baudis]

Dear diary, on Mon, Sep 25, 2006 at 01:04:41AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
> 
> > Dear diary, on Mon, Sep 25, 2006 at 12:34:24AM CEST, I got a letter
> > where Santi <sbejar@gmail.com> said that...
> >> It could be I'm wrong (for sure, I miss something), but I see the
> >> branches/ files like [remote] sections files with just one fetch:
> >> 
> >> .git/branches/git:
> >> git://...../git.gi
> >> 
> >> would be:
> >> 
> >> [remote "git"]
> >> url=git://...../git.git
> >> fetch=refs/heads/master:refs/heads/git
> > 
> > That's basically right, the point is that with moving to remotes
> > support, we will make each remote live in its own separate namespace,
> 
> Which is overkill if we fetch only from one directory.

Why?

> Besides using separate remotes (hmmm, we should add support for
> refs/remotes/ in gitweb) is a policy decision.

Cogito's designed so that users don't have to _care_ about the policy at
this level and it will just magically work for them, sensibly. If you
care enough, you can just modify the config file manually.

> On somewhat unrelated issue: should git-clone create [remote] section
> (and perhaps [branch] sections) instead of remotes file?

Ideally, I would hope for .git/remotes/ to be officially deprecated...
(perhaps after the next release?)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: [CFH] Remotes conversion script

[Santi]

2006/9/25, Jakub Narebski <jnareb@gmail.com>:
> Johannes Schindelin wrote:
>
> > On Sun, 24 Sep 2006, Jakub Narebski wrote:
> >
> >> If I remember correctly currently only some functionality provided by
> >> remotes file can be provided by [remote] and [branch] sections of git
> >> config.
> >
> > ... and what might the lacking functionality be?
>
> What about
>         Pull: +refs/heads/pu:refs/heads/pu
> functionality, i.e. allowing force-update (non fast-forward) fetches?

[remote "git"]
url = git://.../git.git
fetch = +refs/heads/pu:refs/heads/pu

>
> > .git/remotes/<name>    config
> >
> > URL:                   remote.<name>.url
> > Pull:                  remote.<name>.fetch
> > Push:                  remote.<name>.push
> >
> > You can even have multiple entries in the config, and it behaves as if you
> > had multiple lines in .git/remotes/<name>.
>
> And first pull line is default branch to merge, all the rest is marked
> as not-for-merge?

The same way as with .git/remotes/.

the .git/remotes/ files and the [remote] sections are equivalent, modulo bugs.

   Santi

Re: [CFH] Remotes conversion script

[Jakub Narebski]

Petr Baudis wrote:

> Dear diary, on Mon, Sep 25, 2006 at 01:04:41AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Petr Baudis wrote:
>> 
>> > Dear diary, on Mon, Sep 25, 2006 at 12:34:24AM CEST, I got a letter
>> > where Santi <sbejar@gmail.com> said that...
>> >> It could be I'm wrong (for sure, I miss something), but I see the
>> >> branches/ files like [remote] sections files with just one fetch:
>> >> 
>> >> .git/branches/git:
>> >> git://...../git.gi
>> >> 
>> >> would be:
>> >> 
>> >> [remote "git"]
>> >> url=git://...../git.git
>> >> fetch=refs/heads/master:refs/heads/git
>> > 
>> > That's basically right, the point is that with moving to remotes
>> > support, we will make each remote live in its own separate namespace,
>> 
>> Which is overkill if we fetch only from one directory.
> 
> Why?

s/directory/repository/ of course. And as of why: I'd rather have 'next',
'maint, 'html', 'man' in main namespace (with 'origin' substituting
'master') instead of remotes/origin/next etc.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [CFH] Remotes conversion script

[Petr Baudis]

Dear diary, on Mon, Sep 25, 2006 at 01:40:26AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> s/directory/repository/ of course. And as of why: I'd rather have 'next',
> 'maint, 'html', 'man' in main namespace (with 'origin' substituting
> 'master') instead of remotes/origin/next etc.

Well, I don't know. Cogito should stay simple (and stupid) and if you
introduce too much choice, you will lose that. Especially if the choice
is in something already so confusing as branching. And for larger
repositories or more complex distributed branching situations, the
separated-remotes model is clearly superior, so I'd rather keep it for
the simpler cases as well, since if it introduces any hassle, I believe
it's only very minor (and pays off in the long run for the simpler
setups as well, I believe).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)