Hi Guys,
I think I have got some trouble when I use `git clone --depth=n` command. Take a real repo for example:
`git clone https://github.com/douglarek/vimrc.git --depth=1`
then I use `git log`:
so the two results are not same, is it a bug? or it should be so?
My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 1.8.1.4 +.
Thanks and Best regards
Lingchao Xin
From: Stefan Beller <hidden> Date: 2016-06-15 22:58:25
On 08/14/2013 10:20 AM, XinLingchao wrote:
Hi Guys,
I think I have got some trouble when I use `git clone --depth=n` command. Take a real repo for example:
`git clone https://github.com/douglarek/vimrc.git --depth=1`
then I use `git log`:
so the two results are not same, is it a bug? or it should be so?
My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 1.8.1.4 +.
Thanks and Best regards
Lingchao Xin --
Date: Wed, 14 Aug 2013 10:51:53 +0200
From: stefanbeller@googlemail.com
To: douglarek@outlook.com
CC: git@vger.kernel.org; junchunx.guan@gmail.com
Subject: Re: About *git clone --depth=n* puzzle
On 08/14/2013 10:20 AM, XinLingchao wrote:
quoted
Hi Guys,
I think I have got some trouble when I use `git clone --depth=n` command. Take a real repo for example:
`git clone https://github.com/douglarek/vimrc.git --depth=1`
then I use `git log`:
so the two results are not same, is it a bug? or it should be so?
My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 1.8.1.4 +.
Thanks and Best regards
Lingchao Xin --
Stefan, I do NOT think so, the key point is not about the depth limit, it is about whether remote clone depth equals local clone depth.
cheers
Lingchao Xin
Stefan, I do NOT think so, the key point is not about the depth limit,
it is about whether remote clone depth equals local clone depth.
I do not think it is about local vs remote, but rather about which
version of git the remote side is running. Prior to 682c7d2
(upload-pack: fix off-by-one depth calculation in shallow clone,
2013-01-11), a shallow clone always returned one extra commit. That fix
went into v1.8.2.
So if you have a post-v1.8.2 git client, a local clone will use the same
git version as the "remote" side of the connection. But if you are
contacting a remote server, the results you get will depend on what
version of git is running on the remote server.
And as the example you showed uses github.com as the remote, and as I
happen to know that GitHub's servers do not currently have 682c7d2, you
would see the old behavior.
-Peff
Stefan, I do NOT think so, the key point is not about the depth limit,
it is about whether remote clone depth equals local clone depth.
I do not think it is about local vs remote, but rather about which
version of git the remote side is running. Prior to 682c7d2
(upload-pack: fix off-by-one depth calculation in shallow clone,
2013-01-11), a shallow clone always returned one extra commit. That fix
went into v1.8.2.
So if you have a post-v1.8.2 git client, a local clone will use the same
git version as the "remote" side of the connection. But if you are
contacting a remote server, the results you get will depend on what
version of git is running on the remote server.
And as the example you showed uses github.com as the remote, and as I
happen to know that GitHub's servers do not currently have 682c7d2, you
would see the old behavior.
-Peff
On Wed, Aug 14, 2013 at 3:20 PM, XinLingchao [off-list ref] wrote:
Hi Guys,
I think I have got some trouble when I use `git clone --depth=n` command. Take a real repo for example:
`git clone https://github.com/douglarek/vimrc.git --depth=1`
then I use `git log`:
so the two results are not same, is it a bug? or it should be so?
My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 1.8.1.4 +.
The fix is at the server side. >=1.8.2 corrects --depth, which is what
you use for file://. github is still on 1.8.1.6, which does not have
that fix. Oh and the commit is 682c7d2 (upload-pack: fix off-by-one
depth calculation in shallow clone - 2013-01-11)
--
Duy