i can see the standard use of "--depth" when set to precisely one,
for CI/CD systems that don't need any history. but what does it mean
to say, eg, "--depth 10"?
the man page explains that as "a history truncated to the specified
number of commits", but what does mean in the sense of branchi
On Sat, Oct 12, 2019 at 06:31:02PM -0400, Teddy Reed wrote:
> Hello, I am trying to debug an issue where a shallow clone (--depth=1)
> fails when the reference is the tip of a tag on a GitHub repository.
>
> The git client works on versions below 2.22.0-rc0 up until commit
> 34066
Hello, I am trying to debug an issue where a shallow clone (--depth=1) fails
when the reference is the tip of a tag on a GitHub repository.
The git client works on versions below 2.22.0-rc0 up until commit 34066f06,
"fetch: do not consider peeled tags as advertised tips". That commit
Hello Giuseppe, Philip and Jeff,
On 2019-09-02T16:08:54+0200, Giuseppe Crinò wrote:
> To my understanding both questions are solved by
> * https://stackoverflow.com/a/47720414/2219670
> * https://stackoverflow.com/a/12704727/2219670
On 2019-09-02T17:52:19+0200, Philip Oakley wrote:
> Start by ge
fatal: No names found, cannot describe anything.
>
> The tags get lost while doing a shallow clone.
Right. As noted elsewhere in the thread, this is the expected behavior
of Git. But what you want is perfectly reasonable; there's just not a
good way to do it yet.
> I'd figure one o
Hi Reino
On 01/09/2019 12:07, Reino Wijnsma wrote:
Hello git@vger.kernel.org,
Two days ago I started https://github.com/mstorsjo/fdk-aac/issues/107, asking
how to retrieve the fdk-aac version-string on a shallow clone.
My question was of course not fdk-aac related, so Martin Storsjö suggested
> I'd figure one of these options would be to clone everything from tag
> v2.0.0 onward, but if so how would I do that?
> As another option I was thinking; maybe it's possible to do git describe
> --tags on the remote repo?
To my understanding both questions are solved by
* https://stackoverflow
Hello git@vger.kernel.org,
Two days ago I started https://github.com/mstorsjo/fdk-aac/issues/107, asking
how to retrieve the fdk-aac version-string on a shallow clone.
My question was of course not fdk-aac related, so Martin Storsjö suggested I'd
try here. It basicly comes down to this:
ion/gitmodules.txt
> index 8f7c50f..6f39f24 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -84,8 +84,8 @@ submodule..ignore::
>
> submodule..shallow::
> When set to true, a clone of this submodule will be performed as a
> - sha
/gitmodules.txt
@@ -84,8 +84,8 @@ submodule..ignore::
submodule..shallow::
When set to true, a clone of this submodule will be performed as a
- shallow clone unless the user explicitly asks for a non-shallow
- clone.
+ shallow clone (with a history depth of 1) unless the user
his patch:
>
>> OPT_STRING_LIST(0, "shallow-exclude", &option_not, N_("revision"),
>> - N_("deepen history of shallow clone by excluding
>> rev")),
>> + N_("deepen history of shallow clon
possible I botched it and reached a wrong conclusion above.
If we can use the command to make it shallower, then the phrase
"deepen" would probably be what we need to be fixing in this patch:
> OPT_STRING_LIST(0, "shallow-exclude", &option_not, N_("revision"),
On Tue, Dec 6, 2016 at 1:28 AM, Junio C Hamano wrote:
> I however offhand do not think the feature can be used to make the
> repository shallower
I'm pretty sure it can, though it's a waste because you should be able
to shorten your history without talking to a remote server. But that
no-remote s
6c76a6e..e3cb808 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -99,7 +99,7 @@ static struct option builtin_clone_options[] = {
> OPT_STRING(0, "shallow-since", &option_since, N_("time"),
> N_("create a shallow clone since a specific
a/builtin/clone.c b/builtin/clone.c
index 6c76a6e..e3cb808 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -99,7 +99,7 @@ static struct option builtin_clone_options[] = {
OPT_STRING(0, "shallow-since", &option_since, N_("time"),
N_("creat
On Mon, Aug 15, 2016 at 03:53:48PM +0300, Arkady Shapkin wrote:
> So it will work only if github update their server configuration
> (boringssl submodule on github)?
Correct.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel
So it will work only if github update their server configuration
(boringssl submodule on github)?
2016-08-15 15:47 GMT+03:00 Jeff King :
> On Mon, Aug 15, 2016 at 03:29:14PM +0300, Arkady Shapkin wrote:
>
>> Thank you, after updating to "2.9.3.windows.1" options "--recursive
>> --depth 1" now work
On Mon, Aug 15, 2016 at 03:29:14PM +0300, Arkady Shapkin wrote:
> Thank you, after updating to "2.9.3.windows.1" options "--recursive
> --depth 1" now works.
>
> But "--recursive --shallow-submodules" and "--recursive
> --shallow-submodules --depth 1" still doesn't work.
It does "work", but the
Thank you, after updating to "2.9.3.windows.1" options "--recursive
--depth 1" now works.
But "--recursive --shallow-submodules" and "--recursive
--shallow-submodules --depth 1" still doesn't work.
2016-08-15 15:04 GMT+03:00 Jeff King :
> On Mon, Aug 15, 2016 at 02:20:27PM +0300, Arkady Shapkin w
On Mon, Aug 15, 2016 at 02:20:27PM +0300, Arkady Shapkin wrote:
> I am trying clone repository by tag with recursive submodules init,
> but for one submodule it doesn't work.
> What I'm doing wrong?
Nothing. See 18a74a0 (clone: do not let --depth imply
--shallow-submodules, 2016-06-19).
> >git -
Hi,
I am trying clone repository by tag with recursive submodules init,
but for one submodule it doesn't work.
What I'm doing wrong?
>git clone https://github.com/grpc/grpc.git --recursive --depth 1 dsad5
Cloning into 'dsad5'...
remote: Counting objects: 7475, done.
remote: Compressing objects:
> fetch-pack wants to see the shallow list before proceeding. But
> since it has no actual commits to negotiate, the negotiation is a
> noop. So probably this case could actually happen in a single
> request.
I seem to recall our discussion a few months(?) ago about
On Tue, Jun 21, 2016 at 11:23:03AM +, Eric Wong wrote:
> I noticed "fatal: The remote end hung up unexpectedly" in server
> logs from shallow clones. Totally reproducible in the test
> cases, too. The following change shows it:
> [...]
> [Tue Jun 21 11:07:41.391269 2016] [cgi:error] [pid 215
d.sh
+++ b/t/t5561-http-backend.sh
@@ -132,5 +132,11 @@ test_expect_success 'server request log matches test
results' '
test_cmp exp act
'
+test_expect_success 'shallow clone' '
+ config http.uploadpack true &&
+ git clone --depth=
ression.
Yep, it looks good to me.
> +test_expect_success 'shallow clone does not imply shallow submodule' '
> + test_when_finished "rm -rf super_clone" &&
> + git clone --recurse-submodules --depth 2 "file://$pwd/." super_clone &
On Mon, Jun 20, 2016 at 10:14:47AM -0700, Stefan Beller wrote:
> > This follows the style of the other tests, so it's the right thing here.
> > But as a style suggestion, I think:
> >
> > git -C super_clone/sub log --oneline >lines &&
> > test_line_count = 3 lines
> >
> > is nicer than the sub
: do not let --depth imply --shallow-submodules" will actually test
>> for the regression.
>
> Yep, it looks good to me.
>
>> +test_expect_success 'shallow clone does not imply shallow submodule' '
>> + test_when_finished "rm -rf super_clone" &
llow
submodule' '
)
'
-test_expect_success 'shallow clone does not imply shallow submodule' '
+test_expect_success 'shallow clone with shallow submodule' '
test_when_finished "rm -rf super_clone" &&
git clone --recurse-submodules --depth 2
..5049663 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -196,6 +196,11 @@ objects from the source repository into a pack in the
cloned repository.
--shallow-since=::
Create a shallow clone with a history after the specified time.
+--shallow-exclude
=::
+ Create a shallow clone with a history after the specified time.
+
--[no-]single-branch::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
diff --git a/builtin/clone.c b/builtin/clone.c
index bcba080
/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -196,6 +196,11 @@ objects from the source repository into a pack in the
cloned repository.
--shallow-since=::
Create a shallow clone with a history after the specified time.
+--shallow-exclude=::
+ Create a shallow clone with a
=::
+ Create a shallow clone with a history after the specified time.
+
--[no-]single-branch::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
diff --git a/builtin/clone.c b/builtin/clone.c
index bcba080
@@ static struct option builtin_clone_options[] = {
> N_("create a shallow clone of that depth")),
> OPT_STRING(0, "shallow-since", &option_since, N_("time"),
> N_("create a shallow clone s
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -193,6 +193,9 @@ objects from the source repository into a pack in the
cloned repository.
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
+--shallow-since=::
+ Create a shallow clone
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -196,6 +196,11 @@ objects from the source repository into a pack in the
cloned repository.
--shallow-since=::
Create a shallow clone with a history after the specified time.
+--shallow-exclude=::
+ Create a shallow clone
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -193,6 +193,9 @@ objects from the source repository into a pack in the
cloned repository.
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
+--shallow-since=::
+ Create a shallow clone
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -196,6 +196,11 @@ objects from the source repository into a pack in the
cloned repository.
--shallow-since=::
Create a shallow clone with a history after the specified time.
+--shallow-exclude=::
+ Create a shallow clone
194,9 @@ objects from the source repository into a pack in the
> cloned repository.
> `--no-single-branch` is given to fetch the histories near the
> tips of all branches.
>
> +--shallow-since=::
> + Create a shallow clone with a history after the specified time.
> +
&
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -197,6 +197,11 @@ objects from the source repository into a pack in the
cloned repository.
--shallow-since=::
Create a shallow clone with a history after the specified time.
+--shallow-exclude=::
+ Create a shallow clone
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -194,6 +194,9 @@ objects from the source repository into a pack in the
cloned repository.
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
+--shallow-since=::
+ Create a shallow clone
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
Signed-off-by: Stephen P. Smith
---
Notes:
The review comments for the user guide update[1] suggested a change
in the definition of a
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -195,6 +195,11 @@ objects from the source repository into a pack in the
cloned repository.
--since=::
Create a 'shallow' clone with a history after the specified time.
+--not=::
+ Create a 'shallow'
/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -192,6 +192,9 @@ objects from the source repository into a pack in the
cloned repository.
Create a 'shallow' clone with a history truncated to the
specified number of revisions.
+--since=::
+ Create a '
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
Signed-off-by: Stephen P. Smith
---
Documentation/glossary-content.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
---
Documentation/glossary-content.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/glossary-content.txt
b
On Mon, Dec 21, 2015 at 9:09 PM, Stephen P. Smith wrote:
> There are several places in the documentation that
> the term shallow clone is used. Defining the term
> enables its use elsewhere with a known definition.
>
> Signed-off-by: Stephen P. Smith
> ---
> diff --git a/D
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
Signed-off-by: Stephen P. Smith
---
Documentation/glossary-content.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation
On Mon, Dec 07, 2015 at 01:27:51PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think one thing I was missing is that we need to just grab the
> > _object_, but we need to realize that the ref needs updating[1]. So we
> > cannot skip backfill of any tag that we do not already have, e
Jeff King writes:
> I think one thing I was missing is that we need to just grab the
> _object_, but we need to realize that the ref needs updating[1]. So we
> cannot skip backfill of any tag that we do not already have, even if we
> already have the tag object.
> ...
> [1] I'm still puzzled why
On Mon, Dec 7, 2015 at 8:57 PM, Jason Paller-Rzepka wrote:
> Duy, you mentioned that depth=0 means "do not change depth". I assume that
> means the server should use exactly the shallows that the client sent, and
> it does not need to traverse the tree or modify the shallow or unshallow
> sets at
I should point out that I never saw a "deepen 0" line. Rather, I saw
git send "option depth 0" to the remote helper.
Duy, you mentioned that depth=0 means "do not change depth". I assume
that means the server should use exactly the shallows that the client
sent, and it does not need to traverse t
On Sun, Dec 6, 2015 at 8:01 AM, Jeff King wrote:
> On Sun, Dec 06, 2015 at 01:37:18AM -0500, Jeff King wrote:
>
>> And indeed, replacing the logic with what I wrote does make the backfill
>> go away in my test case. But it's so far from what is there that I feel
>> like I must be missing something
On Sun, Dec 06, 2015 at 01:37:18AM -0500, Jeff King wrote:
> And indeed, replacing the logic with what I wrote does make the backfill
> go away in my test case. But it's so far from what is there that I feel
> like I must be missing something.
I think one thing I was missing is that we need to ju
On Sat, Dec 05, 2015 at 08:00:28PM -0800, Junio C Hamano wrote:
> > I suppose followtags feature has been around long enough that we can
> > simply trust that and skip the second fetch?
>
> H, I wonder why the code needs the backfill fetch while talking
> to a server that has the include-tag
Duy Nguyen writes:
> On Fri, Dec 4, 2015 at 11:45 PM, Junio C Hamano wrote:
> ...
>> just like a regular fetch that auto-follows tags, where it has to
>> make a second fetch if the primary fetch fails to include everything
>> that is needed for propagating the tag for whatever reason.
>>
>> Havi
On Fri, Dec 4, 2015 at 11:45 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>>> But why would fetching a tag (or set of tags) merit a depth of zero?
>>> Doesn't depth 1 mean "give me the the objects, and none of their
>>> descendants"? Why use 0?
>>
>> That comes from this line:
>>
>> transpo
Jeff King writes:
>> But why would fetching a tag (or set of tags) merit a depth of zero?
>> Doesn't depth 1 mean "give me the the objects, and none of their
>> descendants"? Why use 0?
>
> That comes from this line:
>
> transport_set_option(transport, TRANS_OPT_DEPTH, "0");
>
> That line blam
clone --bare git://github.com/git/git src.git
# do this for each test run
rm -rf repo
git clone --no-local --depth=1 src.git repo
cd repo
echo "==> unshallow" &&
git fetch --progress --unshallow 2>&1 | grep remote
And you can see that there are two separate secti
Jeff King writes:
> This seems to reproduce consistently for me:
>
> $ git clone --depth=1 git://github.com/git/git
> Cloning into 'git'...
> remote: Counting objects: 2925, done.
> remote: Compressing objects: 100% (2602/2602), done.
> remote: Total 2925 (delta 230), reused 2329 (delta
On Fri, Dec 04, 2015 at 04:38:16PM -0500, Jason Paller-Rzepka wrote:
> It appears that it happens when the shallow history grows to include a
> commit that's pointed to by a previously unseen tag. For example,
> when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
> fetch takes
I can reproduce it now. Instead of using my $random version, I just
needed origin/master
to reproduce.
The second fetch is invoked via
(as outputted via GIT_TRACE=1 git -C git fetch --depth=8)
13:44:56.863841 run-command.c:343 trace: run_command:
'fetch-pack' '--stateless-rpc' '--stdin' '--
2015 at 11:35 AM, Jason Paller-Rzepka
>> wrote:
>> > Hi all,
>> >
>> > Would anyone be willing to help me understand some shallow-clone
>> > behavior? (I found a bug in Dulwich, and I'm looking for some context
>> > so I can determine how to fix i
On Fri, Dec 4, 2015 at 1:27 PM, Jeff King wrote:
>>
>> and could not see a second fetch, but only a
>> fetch-pack with --depth=2147483647
>
> This seems to reproduce consistently for me:
>
> $ git clone --depth=1 git://github.com/git/git
I used the http protocol, so I guess that's the differenc
On Fri, Dec 04, 2015 at 12:46:59PM -0800, Stefan Beller wrote:
> On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
> wrote:
> > Hi all,
> >
> > Would anyone be willing to help me understand some shallow-clone
> > behavior? (I found a bug in Dulwich, and I'
On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
wrote:
> Hi all,
>
> Would anyone be willing to help me understand some shallow-clone
> behavior? (I found a bug in Dulwich, and I'm looking for some context
> so I can determine how to fix it.)
>
> I learned that c
Hi all,
Would anyone be willing to help me understand some shallow-clone
behavior? (I found a bug in Dulwich, and I'm looking for some context
so I can determine how to fix it.)
I learned that cgit sometimes performs two fetches for a `git fetch
--unshallow`: one with depth 'infini
ll existing refs have the same history as the ones from the
> source repository. If the source repository is complete, this removes
> all limitations imposed by shallow repositories.
OK, I can understand that description a lot easier than the original
one.
>>> ++
>>&g
the new paragraph above already covers this case too.
>> ++
>> +Note that if the repository is created with --single-branch, which is
>> +default for a shallow clone, only one ref is completed. `--unshallow`
>> +does not fetch all remaining refs from source repository.
>
s of current repository have the same history as in
> +the source repository.
Makes sense, modulo "so that the all existing refs" sounds strange
to my ears ("all the existing refs" perhaps).
> ++
> +Note that if the repository is created with --single-branch, which
> look into it.
> We are a small branch of a bigger company and our connection to the
> company's source servers is really slow, so just to quickly start it
> up, I decided to take a shallow clone (that's what it is for, right?).
> After a while we realized, the clone I have m
x27;s source servers is really slow, so just to quickly start it
up, I decided to take a shallow clone (that's what it is for, right?).
After a while we realized, the clone I have made was not sufficient
and was missing some newest work done on the project.
I did "git fetch --unshallow&
On 2014-12-07 12.44, Duy Nguyen wrote:
>> Is this a known issue/problem ?
>
> No.
>
Thanks everybody for the support.
The machine was equipped with git version 1.7.10.4 in /usr/bin.
I installed 2.1 or so under /usr/local/bin, (and even /root/bin)
thinking that this would help, but it didn't.
On Sat, Dec 6, 2014 at 7:23 PM, Torsten Bögershausen wrote:
> I share a bare repo with Sparkleshare which does an auto-synch.
> Now the synch had stopped, and trying to push to the central repo
> by hand gives this:
>
>
>
> git push origin master
> fatal: protocol error: expected old/new/ref, got
Since v1.9.0 (14 Feb '14.) you can do various push/pull from a shallow
clone (I'd asked this way back
http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone
and noted when it was corrected/improved)
That's not to say that you don't have to take care ab
On 06/12/2014 19:23, Torsten Bögershausen wrote:
> I think I started to clone the repo in a shallow way
> (SparkleShare asked if I want to clone the complete history,
> and I probably answered "no" )
>
> Is there a way to repair this situation ?
> (Except doing a complete re-clone ?)
>
I think git
I share a bare repo with Sparkleshare which does an auto-synch.
Now the synch had stopped, and trying to push to the central repo
by hand gives this:
git push origin master
fatal: protocol error: expected old/new/ref, got 'shallow
72fb4080921221293e28a97a0e8c78d6100c5186'
fatal: The remote end
pack in the
cloned repository.
--depth ::
Create a 'shallow' clone with a history truncated to the
- specified number of revisions.
+ specified number of revisions. If `--recursive` was also specified
+ the depth value will be passed to all submodules with
pack in the
cloned repository.
--depth ::
Create a 'shallow' clone with a history truncated to the
- specified number of revisions.
+ specified number of revisions. If `--recursive` was also specified,
+ the depth value will be passed to all submodules with
On Tue, Aug 19, 2014 at 6:11 PM, Steven Evergreen
wrote:
> Hi, everyone. I'm trying to perform a shallow clone with visibility of
> all remote branches.
>
> git clone REPO --depth 1 --no-single-branch
>
> is consistently giving me
>
> Cloning into 'REPONAME
Hi, everyone. I'm trying to perform a shallow clone with visibility of
all remote branches.
git clone REPO --depth 1 --no-single-branch
is consistently giving me
Cloning into 'REPONAME'...
fatal: (null) is unknown object
remote: Total 0 (delta 0), reused 0 (delta 0)
fatal: recurs
On wo, 2014-05-28 at 21:16 +0700, Duy Nguyen wrote:
> On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer wrote:
> > I then clone the bare repository with --depth 1.
> >
> > git clone file:///path/to/bare.git ./clone --depth 1
> >
> > It always returns the last two commits. If I specify --depth 2 it r
On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer wrote:
> I then clone the bare repository with --depth 1.
>
> git clone file:///path/to/bare.git ./clone --depth 1
>
> It always returns the last two commits. If I specify --depth 2 it returns
> the last 3 commits.
>
> If I use --depth 1 on a Github
Hi there Git developers,
I'm not sure if I found a bug in the command
git clone repo.git cloned_repo --depth 1
I follow these steps:
git init
echo "First commit" >> test.txt
git add -A
git commit -am "First commit"
echo "Second commit" >> test.txt
git commit -am "Second commit"
echo "Third c
Now that git supports data transfer from or to a shallow clone, these
limitations are not true anymore.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-clone.txt | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/receive-pack.c | 3 ---
t/t5537-push-shallow.sh | 35 +++
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 5c85bb4..78fe8ee 100644
--- a/builtin/r
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 3 ---
send-pack.c | 19 +--
t/t5537-push-shallow.sh | 25 +
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 664dd
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 4 +++-
t/t5537-push-shallow.sh | 38 ++
transport.c | 5 ++---
3 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index ea2ab
+ if (!args->dry_run)
+ advertise_shallow_grafts(out);
+
/*
* Finally, tell the other end!
*/
diff --git a/t/t5537-push-shallow.sh b/t/t5537-push-shallow.sh
new file mode 100755
index 000..650c31a
--- /dev/null
+++ b/t/t5537-push-shallow.sh
@@ -
ry
fetch: support fetching from a shallow repository
upload-pack: make sure deepening preserves shallow roots
fetch: add --update-shallow to accept refs that update .git/shallow
receive-pack: reorder some code in unpack()
receive/send-pack: support pushing from a shallow clone
New var GIT_
On Sun, Nov 24, 2013 at 10:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> Pushing from a shallow clone using today's send-pack and receive-pack
> may work, if the transferred pack does not end up at any graft
> points. If it does, recent receive-pack that does connectivity check
> will re
Now that git supports push/pull from/to a shallow clone, these
limitations are not true anymore.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-clone.txt | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/receive-pack.c | 3 ---
t/t5537-push-shallow.sh | 35 +++
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 366ecde..ec681ba 100644
--- a/builtin/
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 5 -
t/t5537-push-shallow.sh | 38 ++
transport.c | 5 ++---
3 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 5db
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 3 ---
send-pack.c | 19 +--
t/t5537-push-shallow.sh | 25 +
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 0031
Pushing from a shallow clone using today's send-pack and receive-pack
may work, if the transferred pack does not end up at any graft
points. If it does, recent receive-pack that does connectivity check
will reject the push. If receive-pack is old and does not have the
connectivity check
fetch: add --update-shallow to get refs that require updating .git/shallow
Basic shallow fetch/clone support on git protocol
receive-pack: reorder some code in unpack()
Support pushing from a shallow clone
New var GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses
connected.c:
Stefan Näwe wrote:
> Stefan Näwe atlas-elektronik.com> writes:
>> 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
>
> And to answer myself once more:
>
> That's fixed in
>
>6da8bdc fetch-pack: do not remove .git/shallow file when --depth is not
> specified"
>
> Sorry for all
Stefan Näwe atlas-elektronik.com> writes:
> Am 25.09.2013 16:47, schrieb Stefan Näwe:
> This is what it gives me if I use my script (slightly modified
> to also run make) with 'git bisect run':
>
> 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
And to answer myself once more:
Am 25.09.2013 16:47, schrieb Stefan Näwe:
> Just a quick report since I don't have time to bisect now (will do later
> if no other gitster is faster...)
I'd marry 'git bisect' if I wasn't already... ;-)
This is what it gives me if I use my script (slightly modified to also run make)
with 'git bis
Am 25.09.2013 16:47, schrieb Stefan Näwe:
> Just a quick report since I don't have time to bisect now (will do later
> if no other gitster is faster...)
Seems to be somewhere between v1.8.3.1 (OK) and v1.8.3.2 (not OK) !!
>
> When I execute the below script 'git show' crashes. 'git log --onelin
1 - 100 of 143 matches
Mail list logo
