Git Mailing List Archive mirror
 help / color / mirror / Atom feed
@ 2008-06-27 22:08 Junio C Hamano
  2008-06-27 22:14 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2008-06-27 22:08 UTC (permalink / raw)
  To: git

[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

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re:
  2008-06-27 22:08 Junio C Hamano
@ 2008-06-27 22:14 ` Junio C Hamano
  0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2008-06-27 22:14 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

@ 2019-06-19 17:40 Konstantin Matokhin
  0 siblings, 0 replies; 4+ messages in thread
From: Konstantin Matokhin @ 2019-06-19 17:40 UTC (permalink / raw)
  To:; +Cc: Ruslan Petrenko


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:


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?


^ permalink raw reply	[flat|nested] 4+ messages in thread

@ 2023-02-23  6:46 Mustafa Ayvaz
  0 siblings, 0 replies; 4+ messages in thread
From: Mustafa Ayvaz @ 2023-02-23  6:46 UTC (permalink / raw)
  To: git

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 

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.

Mustafá Ayvaz

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-02-23  6:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-23  6:46 Mustafa Ayvaz
  -- strict thread matches above, loose matches on Subject: below --
2019-06-19 17:40 Konstantin Matokhin
2008-06-27 22:08 Junio C Hamano
2008-06-27 22:14 ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).