Hi Aleksey
Thanks for your patch. I added Eric Wong to the Cc list; all git-svn
patches should go to him.
Aleksey Vasenev margtu-f...@ya.ru writes:
---
Can you write a commit message? If you need a guideline for what to
write there, consider this snippet from
On Fri, Nov 22, 2013 at 01:28:59PM -0400, Joey Hess wrote:
Hrm. For --batch, I'd think we would open the whole object and notice
the corruption, even with the current code. But for --batch-check, we
use sha1_object_info, and for an experimental object, we do not need
to de-zlib the object
Trần Ngọc Quân vnwild...@gmail.com writes:
$ git status
fatal: Unable to read current working directory: Kh?ng c? t?p tin ho?c
th? m?c nh? v?y
So, somthing wrong with our charset.
[...]
$ gettext --domain=libc No such file or directory
Không có tập tin hoặc thư mục như vậy
in git's
On Sun, Nov 24, 2013 at 03:44:44AM -0500, Jeff King wrote:
In any code path where we call parse_object, we double-check that the
result matches the sha1 we asked for. But low-level commands like
cat-file just call read_sha1_file directly, and do not have such a
check. We could add it, but I
Hi,
i've recently reinstalled a fresh system (fc20-beta) on my workstation
and observing a big slowdown on git cherry-pick operation (git-1.8.4.2-1).
the previous centos installation with an old git version works faster
(few seconds per cherry pick). now the same operation takes 1 min.
my git
On Sun, Nov 24, 2013 at 7:47 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora pawel.sik...@agmk.net wrote:
i've recently reinstalled a fresh system (fc20-beta) on my workstation
and observing a big slowdown on git cherry-pick operation (git-1.8.4.2-1).
the
On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora pawel.sik...@agmk.net wrote:
i've recently reinstalled a fresh system (fc20-beta) on my workstation
and observing a big slowdown on git cherry-pick operation (git-1.8.4.2-1).
the previous centos installation with an old git version works faster
On 24.11.2013 07:54, Jeff King wrote:
On Sat, Nov 23, 2013 at 05:36:36PM +0100, Stefan Beller wrote:
sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git
Cloning into 'ValyriaTear'...
remote: Counting objects: 21346, done.
remote: Compressing objects: 100% (6307/6307), done.
On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote:
Here is the output of
sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone
https://github.com/Bertram25/ValyriaTear.git tmp
Thanks. I think I see what is going on.
We finish the helper conversation here:
Checking
On 24.11.2013 14:33, Jeff King wrote:
On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote:
Here is the output of
sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone
https://github.com/Bertram25/ValyriaTear.git tmp
Thanks. I think I see what is going on.
We finish the helper
[+cc Daniel, who worked on the curl fix]
On Sun, Nov 24, 2013 at 04:01:43PM +0100, Stefan Beller wrote:
On 24.11.2013 14:33, Jeff King wrote:
On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote:
Here is the output of
sb@sb:/tmp$ GIT_TRANSPORT_HELPER_DEBUG=1 git clone
On 24.11.2013 16:54, Jeff King wrote:
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically
placed calls to ignore SIGPIPE. I wonder if there is another spot that
needs similar treatment. It looks like curl_easy_cleanup is covered,
though, and that's where I would expect
Am 24.11.2013 01:52, schrieb Heiko Voigt:
Hi,
On Sat, Nov 23, 2013 at 09:10:44PM +0100, Jens Lehmann wrote:
Am 22.11.2013 23:09, schrieb Jonathan Nieder:
Heiko Voigt wrote:
After that we can discuss whether add should add submodules that are
tracked but not shown. How about commit -a ?
On 24.11.2013 16:54, Jeff King wrote:
[+cc Daniel, who worked on the curl fix]
On Sun, Nov 24, 2013 at 04:01:43PM +0100, Stefan Beller wrote:
On 24.11.2013 14:33, Jeff King wrote:
On Sun, Nov 24, 2013 at 01:54:34PM +0100, Stefan Beller wrote:
Here is the output of
sb@sb:/tmp$
On Sunday 24 of November 2013 19:47:10 Duy Nguyen wrote:
On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora pawel.sik...@agmk.net wrote:
i've recently reinstalled a fresh system (fc20-beta) on my workstation
and observing a big slowdown on git cherry-pick operation (git-1.8.4.2-1).
the previous
Jeff King p...@peff.net writes:
khash.h | 338
[...]
diff --git a/khash.h b/khash.h
new file mode 100644
index 000..57ff603
--- /dev/null
+++ b/khash.h
@@ -0,0 +1,338 @@
+/* The MIT License
+
+ Copyright (c) 2008, 2009, 2011 by Attractive Chaos
On Sun, 24 Nov 2013, Jeff King wrote:
Hmm. The fix in curl's 7d80ed64e435155 seems to involve strategically placed
calls to ignore SIGPIPE. I wonder if there is another spot that needs
similar treatment. It looks like curl_easy_cleanup is covered, though, and
that's where I would expect
On Sun, Nov 24, 2013 at 10:54:39AM -0500, Jeff King wrote:
Another thought is that the curl fix seems to only kick in when built
with openssl support. I'm not sure I understand how ubuntu's packaging
of curl uses gnutls versus openssl for the shared library. That may be
related.
Debian (and
On 24/11/2013 16:05, Thomas Rast wrote:
Trần Ngọc Quân vnwild...@gmail.com writes:
$ git status
fatal: Unable to read current working directory: Kh?ng c? t?p tin ho?c
th? m?c nh? v?y
So, somthing wrong with our charset.
[...]
Do you know why this suddenly broke?
I think git set CTYPE=C
Compared to v2 [1], v3 grows a bit. The biggest difference is
.git/shallow is not updated by default (except when you clone from
a shallow repository). When you send something, the safe refs that
do not need new shallow roots are accepted at the receiver end, the
others rejected.
To accept those
When we receive a pack and the shallow points from another repository,
we may want to add more shallow points to current repo to make sure no
commits point to nowhere. However we do not want to add unnecessary
shallow points and cut our history short because the other end is a
shallow version of
Dumb commit walker does not care about .git/shallow and until someone
steps up to make it happen, let's not publish shallow clones using
dumb protocols.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
server-info.c | 9 +
1 file changed, 9 insertions(+)
diff --git
If either receive-pack or upload-pack is called on a shallow
repository, shallow graft points will be sent after the ref
advertisement (but before the packet flush), so that the client has
the full shape of the server's commit graph.
This breaks the protocol for all clients trying to push to a
If we borrow objects from another repository, we should also pay
attention to their $GIT_DIR/shallow (and even info/grafts). But
current alternates code does not.
Reject alternate repos that are shallow because we do not do it
right. In future we alternate code may be updated to check
send-pack can send a pack with loose ends to the server. receive-pack
before 6d4bb38 (fetch: verify we have everything we need before
updating our ref - 2011-09-01) does not detect this and keeps the pack
anyway, which corrupts the repository, at least from fsck point of
view.
send-pack will
No callers pass a non-empty pointer as shallow_points at this
stage. As a result, all clients still refuse to talk to shallow
repository on the other end.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch-pack.c | 2 +-
builtin/send-pack.c | 2 +-
connect.c|
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
transport.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/transport.h b/transport.h
index 8f96bed..b3679bb 100644
--- a/transport.h
+++ b/transport.h
@@ -193,10 +193,4 @@ void transport_print_push_status(const char *dest,
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, the
This patch just put together pieces from the previous patches:
- Before getting the new pack, we need to remove all new reachable
shallow roots. The remaining roots may or may not be added to
.git/shallow.
- After getting the pack, walk all new refs until they connect to
current refs,
The gist of cloning a remote shallow repository is simple. The remote
gives you a pack and all its shallow roots. All you need to do is set
your .git/shallow correctly.
The rule to create this .git/shallow is simple and more importantly,
cheap: if a shallow root is found in the pack, it's
This is the preparation for adding --shallow-file to both
unpack-objects and index-pack. To sum up:
- status/code, ip/child, unpacker/keeper and i (now ac) are moved out
to function top level
- successful flow now ends at the end of the function
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
commit.h | 8 +---
fetch-pack.c | 5 +++--
shallow.c | 20 +++-
upload-pack.c | 2 +-
4 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/commit.h b/commit.h
index e1fd587..3af4699 100644
---
This may be needed when a hook is run after a new shallow pack is
received, but .git/shallow is not settled yet. A temporary shallow
file to plug all loose ends should be used instead. GIT_SHALLOW_FILE
is overriden by --shallow-file.
--shallow-file does not work in this case because the hook may
When fetch --depth=N where N exceeds the longest chain of history in
the source repo, usually we just send an unshallow line to the
client so full history is obtained.
When the source repo is shallow we need to make sure to unshallow
the current shallow point _and_ shallow again when the commit
When we receive a pack and the shallow points from another repository,
we may need to add more shallow points to current repo to make sure no
commits point to nowhere. But usually we don't want to do so because
(in future) new shallow points invalidate pack bitmaps and we need to
rebuild them
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fetch-pack.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 0e7483e..35d097e 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -925,6 +925,18 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fetch-pack.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/fetch-pack.h b/fetch-pack.h
index 461cbf3..9b08388 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -8,18 +8,18 @@ struct
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/fetch-options.txt | 6 ++
builtin/fetch.c | 6 +-
fetch-pack.c| 26 ++
fetch-pack.h| 1 +
t/t5536-fetch-shallow.sh| 22
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch-pack.c | 7 +++
remote-curl.c| 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 927424b..aa6e596 100644
--- a/builtin/fetch-pack.c
+++
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitremote-helpers.txt | 7 +++
builtin/fetch-pack.c| 16 +---
remote-curl.c | 30 --
t/t5536-fetch-shallow.sh| 27
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 pclo...@gmail.com
---
Documentation/git-clone.txt | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
connected.c | 42 ++
connected.h | 2 ++
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/connected.c b/connected.c
index fae8d64..427389d 100644
--- a/connected.c
+++ b/connected.c
This is more expensive than the current mode and potentially
invalidates caches like pack bitmaps. It's only enabled if
receive.shallowupdate is on.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 4 ++
builtin/receive-pack.c | 111
clone_local() does not handle $SRC/shallow. It could be made so, but
it's simpler to use fetch-pack/upload-pack instead.
This used by be caught by the check in upload-pack, which is triggered
by transport_get_remote_refs(), even in local clone case. The check is
now gone and
This patch teaches prune to remove shallow roots that are no longer
reachable from any refs (e.g. when the relevant refs are removed).
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/gc.c| 1 +
builtin/prune.c | 4
commit.h| 1 +
shallow.c | 43
On Sun, Nov 24, 2013 at 05:32:34PM +0100, Stefan Beller wrote:
GIT_TRANSPORT_HELPER_DEBUG=1 git clone
https://github.com/Bertram25/ValyriaTear.git
now ends with:
Debug: Remote helper: Waiting...
remote: Counting objects: 21354, done.
remote: Compressing objects: 100% (6249/6249), done.
On Mon, 25 Nov 2013, Jeff King wrote:
Thanks. I'm having trouble reproducing the SIGPIPE locally, but I am able to
see via strace the write we make in curl_multi_cleanup. The call stack is:
curl_multi_cleanup
- close_all_connections
- Curl_disconnect
- Curl_ossl_close
Jonathan I see you participated in bug 6530, mentioned in the big
comment block in init_gettext_charset(). The bug seems fixed since
glibc 2.17. Do you think it's ok to revert the workaround if we detect
the running glibc is fixed (or if it does not run glibc at all)? I
think we could use
51 matches
Mail list logo