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

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.