git@vger.kernel.org

git@vger.kernel.org

[Junio C Hamano]

[jc: trying to resend this message I sent late last night, because vger
did not seem to have relayed it to the list for some unknown reason.]

Some people noticed that they have trouble going to remote site over ssh
transport using 'next' version of git.

A brief git transport primer may be helpful to understand what is going
on.  When you run "git fetch" (and remember, "git pull" runs it before it
runs "git merge") against a remote over ssh transport, it asks the other
side to run "git-upload-pack" program.  We have always used the dashed
form "git-upload-pack" to make this request.  Similarly, "git push" (and
"git send-pack") runs "git-receive-pack" and "git archive --remote" runs
"git-upload-archive" on the other end.

We have promised to move most of the git-$foobar programs out of the end
users' $PATH starting from 1.6.0.  After git-upload-pack moves outside
$PATH, however, asking the shell invoked via ssh on the other and to run
git-upload-pack won't find it, because the program is not found anywhere
on $PATH.  Hence, change to ask for "git upload-pack" is eventually
necessary.  We cannot avoid it.

Now, when the remote side runs pre-1.6.0 software, and the ssh daemon on
it runs a real shell, asking for "git upload-pack" (i.e. dashless form)
does not have any problem.  "git" will be on your $PATH and it always
knows where "git-upload-pack" is found, and it will run the program you
wanted to run just fine.

However, when the remote side does not let you run a real shell, this is
problematic.  For example, your login shell can be set to "git-shell" (git
restricted shell), which refuses to run anything but git-upload-pack,
git-receive-pack, or git-upload-archive.  Specifically, it does not allow
you to run "git" itself with arbitrary arguments.  Asking such a server to
run "git upload-pack" will not work.  gitosis is another example of such a
server.  Both git-shell and gitosis already have patches to prepare them
to accept requests in either forms.

It is still possible to connect to older remote end with new clients, but
you have to explicitly ask for "git-upload-pack" by using --upload-pack=
option when running "git fetch", which is a bit cumbersome.  Hence, we
have to wait before people can update their servers, and then update the
client side to start asking for "git upload-pack" and friends with
dashless form.

The patch to prepare the client side for this was prepared and queued in
"next" a few days ago.  Consider this glitch as a part of proving the
change while in next.  You have a real-world opportunity to make sure that
the workaround to use --upload-pack= actually works with older remote end
and send in success reports ;-)

In other words, Sorry, I screwed up.

I've cut v1.5.4.6 and v1.5.5.5 releases tonight (they are tagged and
pushed out already), both of which contain updates to "git-shell" so that
it accepts both dashed and non-dashed forms, to make it easier for people
to update their servers.  At the same time, the change to the client side
has been reverted from 'next' for now.

Cooking and proving the client side change in next will still be needed,
but we'll postpone it for now.

Also, 1.6.0 will still install git-upload-pack and friends that are needed
on the server side in $(bindir) that is on your $PATH, so that older
clients will still work.

So the timeline will be:

 * Futureproofed "git-shell" and gitosis are released.  People slowly
   start deploying them.  Both old and (unreleased yet) new clients will
   be able to talk to them.

 * 1.6.0 installs git-upload-pack and friends in $(bindir) on your $PATH.
   Both old clients and 1.6.0 clients will ask for git-upload-pack and the
   real shell will still be able to find them.

 * 6 months after 1.6.0 ships, these futureproofed "git-shell" and gitosis
   will be in widespread use and nobody runs older servers anymore.  A
   major release after this happens will change the client to start asking
   for "git upload-pack" (dashless form).

   You would need --upload-pack=git-upload-pack option to talk to ancient
   servers when this happens (and past few days were preview of this).

 * 12 months after that major release ships, these new clients will be in
   widespread use and nobody runs older clients anymore.  A major release
   after this happens will stop installing git-upload-pack and friends in
   $(bindir).

   Older clients (like v1.5.0) would use --upload-pack="git upload-pack"
   to talk to new servers.

Re: git@vger.kernel.org

[Junio C Hamano]

Sorry, while trying to fudge the headers and messages to avoid triggering
vger's spam filter, I managed to mangle the subject of that message.  It
should have read:

Subject: Glitches connecting to existing remote using 'next' git

Adding a 'version' command to the server (was: git@vger.kernel.org)

[Lea Wiemann]

Junio C Hamano wrote:
> It is still possible to connect to older remote end with new clients, but
> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
> option when running "git fetch"

Now that the current git won't work with older servers anyway, what 
about using this opportunity to add a 'version' command to the server? 
With such a command, such problems would seem to be quite easily 
avoidable in the future, since the client can discriminate based on the 
server's version.

I'm not sure how to implement this (the problems seem to be that (a) it 
needs to work with git-shell and real shells, and (b) that older clients 
must not be supplied with a version number in order not to break them), 
but perhaps this is worth pondering.

Apologies if this has been discussed before.

-- Lea

Re: Adding a 'version' command to the server

[Junio C Hamano]

Lea Wiemann <lewiemann@gmail.com> writes:

> Junio C Hamano wrote:
>
>> It is still possible to connect to older remote end with new clients, but
>> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
>> option when running "git fetch"
>
> Now that the current git won't work with older servers anyway,...

Whoa, Wait.  Who said that?

Re: Adding a 'version' command to the server

[Lea Wiemann]

Junio C Hamano wrote:
> Lea Wiemann <lewiemann@gmail.com> writes:
>> Junio C Hamano wrote:
>>> It is still possible to connect to older remote end with new clients, but
>>> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
>>> option when running "git fetch"
>>
>> Now that the current git won't work with older servers anyway,...
> 
> Whoa, Wait.  Who said that?

I meant "now that the current git won't work with *some* older servers 
*without adding an option*".  Or did I misunderstand you?

-- Lea

Re: Adding a 'version' command to the server (was: git@vger.kernel.org)

[Alex Riesen]

Lea Wiemann, Sat, Jun 28, 2008 01:07:40 +0200:
> Junio C Hamano wrote:
>> It is still possible to connect to older remote end with new clients, but
>> you have to explicitly ask for "git-upload-pack" by using --upload-pack=
>> option when running "git fetch"
>
> Now that the current git won't work with older servers anyway, what  
> about using this opportunity to add a 'version' command to the server?  
> With such a command, such problems would seem to be quite easily  
> avoidable in the future, since the client can discriminate based on the  
> server's version.

And exactly how are the incompatibility problems avoided? By denying
the service if the versions don't match?

Re: Adding a 'version' command to the server

[Lea Wiemann]

Alex Riesen wrote:
> And exactly how are the incompatibility problems avoided? By denying
> the service if the versions don't match?

No, by talking to older servers in a way they understand it.  So for 
instance it would call "git-upload-pack" instead of "git upload-pack".

(See also the SSH protocol with two versions, and I think Subversion's 
svnserve also somehow identifies its own capabilities and/or version.)

-- Lea

Re: Adding a 'version' command to the server

[Shawn O. Pearce]

Lea Wiemann <lewiemann@gmail.com> wrote:
> Alex Riesen wrote:
> >And exactly how are the incompatibility problems avoided? By denying
> >the service if the versions don't match?
> 
> No, by talking to older servers in a way they understand it.  So for 
> instance it would call "git-upload-pack" instead of "git upload-pack".
> 
> (See also the SSH protocol with two versions, and I think Subversion's 
> svnserve also somehow identifies its own capabilities and/or version.)

We already have both sides of a git native connection select
functions to be used in the protocol based upon both sides having
the necessary capabilities.  This is in heavy use today for things
like thin packs, sideband progress messages and remote deletion of
branches through git-push.

So we're doing what you suggest.

The problem we are faced with right now is when invoking Git over
SSH we need to pass some string to the remote shell and expect
the remote shell to start up the program we need to talk to.
Without that program running there is nothing to ask the other side
its version.  :-(

This should be a one-time transition pain, as the original git
developers used git-foo-command style, but users today want just
"git foo-command" style, to reduce the number of commands they
see with tab completion.  Its the price we/they pay for making
that sort of change this late in the project.

I'm not sure when SVN start supporting "svn serve" over SSH.  It may
have been quite a while after they were already self-hosting, as
they started out with HTTP WebDAV as the only protocol.  Thus they
may have already been heavily into the "svn foo" style of command
invocation and never made the "misstep" that Git made.

Of course SVN has made _many_ other "missteps" that Git has done
right since day 1.  Like merge support.  :-)

Nobody is perfect.  Not even the Git developers.

-- 
Shawn.

git@vger.kernel.org

[Konstantin Matokhin]

Hello,

I have a question about sparse checkout. Git version 2.17.1
For some reason it checks out files from not specified folders. 
My .git/info/sparse-checkout has two lines:

frontend/
common/

However backend/ is also created with some files in it (not all)

Is it a known bug? 
Any workaround to have only desired frontend/ and common/ checked out?

Thanks,
Konstantin.

git@vger.kernel.org

[Mustafa Ayvaz]

Bom dia git,

Sou o advogado Mustafa Ayvaz, advogado pessoal do falecido Sr. 
Robert, que perdeu a vida devido ao coronavírus, contraído 
durante sua viagem de negócios à China. Entrei em contato com 
você para trabalhar comigo na transferência de um fundo: 
$4,420,000.00 (quatro milhões, quatrocentos e vinte mil dólares) 
legado deixado por ele.

Procurei minuciosamente o parente mais próximo de meu cliente 
falecido, mas falhei porque não tenho sua residência atual e 
detalhes de contato. Enquanto pesquisava, encontrei seu perfil 
com o mesmo sobrenome e na mesma localidade com o parente mais 
próximo. Decidi entrar em contato com você e usá-lo como parente 
genuíno.

Solicito seu consentimento para apresentá-lo como parente mais 
próximo de meu falecido cliente, já que ambos têm o mesmo 
sobrenome. Os fundos serão então transferidos para você como 
beneficiário e compartilhados de acordo com um padrão/proporção 
de compartilhamento proposto de 60:40, ou seja, 60% para mim e 
40% para você. Por favor, entre em contato comigo imediatamente 
para obter mais informações.

Cumprimentos
Mustafá Ayvaz