Init on push

Init on push

[Robin Rosenberg]

Hi,

I am missing the ability to do this (command line or GUI)

git remote add someremote someurl
git push --init someremote/someurl

The implementation would invoke receive pack on the receiving side with
an --init option. On the server side the repository would be created and
initialized just as one had executed and mkdir and git init --bare.

The target audience is people who are either lazy (like me) or "shellofobic" users.
GUI's would get an extra check box.

This could be extended by passing options to the init switch with init options
for the server side, say --init="--shared=false".

Could a patch for this be acceptable?

-- robin

Re: Init on push

[Junio C Hamano]

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

> git remote add someremote someurl
> git push --init someremote/someurl
>
> The implementation would invoke receive pack on the receiving side with
> an --init option. On the server side the repository would be created and
> initialized just as one had executed and mkdir and git init --bare.

We saw this quite a number of times.  I think it's about time we did
something about it.

But I do not think it is a reasonable design to give receive-pack such an
option.

An easy alternative would be to issue the usual "mkdir && git init" shell
script before spawning receive-pack.  This will limit the feature to
pushing over the ssh transport, and pushing over the git protocol against
a loose git-daemon will not be able to support it.  Also I suspect this
will break sites managed by gitosis, where all repositories are held under
the same UNIX user identity, differenciated only via an environment it
sets based on the ssh key used to make the connection.

I wonder if you can take a middle ground alternative:

 - Make "git push --init [--shared] $site:$there" and "git push --init
   [--shared] git://$site/$there" run "git init -D [--shared] $there"
   followed by "git receive-pack $there";

 - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
   chdird $it" before it does its work.
 
 - Teach "git daemon" about the "init" service, which is disabled by
   default, and can be enabled just like you can enable receive-pack
   there.

If sites like repo.or.cz, github, or managed with gitosis want to use
this, I think you might further need to give "git init -D $there" a hook
to control who can create new repositories at which location (gitosis is
the most interesting case, as described above).

Re: Init on push

[Alexander Gavrilov]

On Sat, Nov 8, 2008 at 10:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> An easy alternative would be to issue the usual "mkdir && git init" shell
> script before spawning receive-pack.  This will limit the feature to
> pushing over the ssh transport, and pushing over the git protocol against
> a loose git-daemon will not be able to support it.  Also I suspect this
> will break sites managed by gitosis, where all repositories are held under
> the same UNIX user identity, differenciated only via an environment it
> sets based on the ssh key used to make the connection.

Gitosis works by replacing the shell with a program called
gitosis-serve, which parses and validates the incoming commands
against the user access configuration. If it sees an unknown command,
it will simply refuse to execute it.

On the other hand it will automatically perform initialization before
calling receive-pack if the user is authorized to write to a certain
path, but the repository does not exist yet.

Alexander

Re: Init on push

[Junio C Hamano]

"Alexander Gavrilov" <angavrilov@gmail.com> writes:

> Gitosis works by replacing the shell with a program called
> gitosis-serve, which parses and validates the incoming commands
> against the user access configuration. If it sees an unknown command,
> it will simply refuse to execute it.

If you implement a new feature by enhancing receive-pack (or anything
else), you obviously cannot use the new feature against an installation
with an older implementation, so what you said is a known.  My point was
how to enhance the receiving end and what constraints we would have in
enhancing it.

> On the other hand it will automatically perform initialization before
> calling receive-pack if the user is authorized to write to a certain
> path, but the repository does not exist yet.

That's good to know.  I also realize that gitosis does not need any hook
for "git init -D $there" to decide whether a new repository can be created
at requested location, as it reads the command line and makes decision
before driving the underlying command in response to the request.

On the other hand, people who enable 'push' access to their git-daemon
would need it, as the daemon would not even know who is asking for --init.

Re: Init on push

[Jakub Narebski]

Junio C Hamano wrote:

>  - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
>    chdird $it" before it does its work.

Shouldn't it be "-C $there" (like make and tar)?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Init on push

[Francis Galiegue]

Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
> Junio C Hamano wrote:
> >  - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
> >    chdird $it" before it does its work.
>
> Shouldn't it be "-C $there" (like make and tar)?

I agree with that. It's pretty much a standard for quite a few "command line 
people", insofar as I always look for such an option in case I want to know 
whether a command has the ability to chdir() to a different directory than 
the current one :p

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris

Re: Init on push

[Junio C Hamano]

Francis Galiegue <fg@one2team.com> writes:

> Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
>> Junio C Hamano wrote:
>> >  - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
>> >    chdird $it" before it does its work.
>>
>> Shouldn't it be "-C $there" (like make and tar)?
>
> I agree with that. It's pretty much a standard for quite a few "command line 
> people", insofar as I always look for such an option in case I want to know 
> whether a command has the ability to chdir() to a different directory than 
> the current one :p

In this particular case, it is not "chdir() before starting" but "mkdir
and then chdir() into it".  Using -C would be counterproductive.

Re: Init on push

[Francis Galiegue]

Le Saturday 08 November 2008 21:38:10 Junio C Hamano, vous avez écrit :
> Francis Galiegue <fg@one2team.com> writes:
> > Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
> >> Junio C Hamano wrote:
> >> >  - Teach "-D $there" option to "git init", which does an "mkdir -p $it
> >> > && chdird $it" before it does its work.
> >>
> >> Shouldn't it be "-C $there" (like make and tar)?
> >
> > I agree with that. It's pretty much a standard for quite a few "command
> > line people", insofar as I always look for such an option in case I want
> > to know whether a command has the ability to chdir() to a different
> > directory than the current one :p
>
> In this particular case, it is not "chdir() before starting" but "mkdir
> and then chdir() into it".  Using -C would be counterproductive.
> --
> 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

I have missed the mkdir part, but then here this is mkdir _-p_...

I mean, what is the cost of mkdir -p the/dir and then git init -C the/dir? I 
don't think it's that good an idea to have git create the directory in this 
case...

Think of what would happen if you git -D a/b, and a is a symlink to, where, 
somewhere (doesn't exist, exists but if you touch it you're {in trouble,good 
for jail time, whatever}).

I personnaly think that the directory creation SHOULD be created to the 
commands that are meant for it, just as git handles dir creation in its own 
space (a git repository).

-- 
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris

Re: Init on push

[Francis Galiegue]

Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit :
[...]
>
> I personnaly think that the directory creation SHOULD be created

I meant "handled", sorry.

-- 
fge

Re: Init on push

[Junio C Hamano]

Francis Galiegue <fg@one2team.net> writes:

> Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit :
> [...]
>>
>> I personnaly think that the directory creation SHOULD be created
>
> I meant "handled", sorry.

Why have we ended up losing the most important Cc: to the original patch
submitter who asked if the idea of his patch is sound?

Re: Init on push

[Francis Galiegue]

Le Sunday 09 November 2008 01:13:11 Junio C Hamano, vous avez écrit :
> Francis Galiegue <fg@one2team.net> writes:
> > Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit :
> > [...]
> >
> >> I personnaly think that the directory creation SHOULD be created
> >
> > I meant "handled", sorry.
>
> Why have we ended up losing the most important Cc: to the original patch
> submitter who asked if the idea of his patch is sound?

Sorry for that. I blindly "replied to all", not seeing that the reply chain 
has been "broken" along the way.

-- 
fge