Re: gettext CTYPE for libc

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 gnu_get_l

Re: error: git-remote-https died of signal 13

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

Re: error: git-remote-https died of signal 13

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), d

[PATCH v3 28/28] prune: clean .git/shallow after pruning objects

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 --- builtin/gc.c| 1 + builtin/prune.c | 4 commit.h| 1 + shallow.c | 43 +++

[PATCH v3 23/28] Support fetch/clone over http

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/gitremote-helpers.txt | 7 +++ builtin/fetch-pack.c| 16 +--- remote-curl.c | 30 -- t/t5536-fetch-shallow.sh| 27 +++ tran

[PATCH v3 26/28] git-clone.txt: remove shallow clone limitations

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-clone.txt

[PATCH v3 24/28] receive-pack: support pushing to a shallow clone via http

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/

[PATCH v3 22/28] remote-curl: pass ref SHA-1 to fetch-pack as well

Signed-off-by: Nguyễn Thái Ngọc Duy --- 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 +++ b/builtin/fetch-pack.c @@

[PATCH v3 19/28] connected.c: add new variant that runs with --shallow-file

Signed-off-by: Nguyễn Thái Ngọc Duy --- 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 @@ -19,17 +19,17 @

[PATCH v3 20/28] receive-pack: allow pushing with new shallow roots

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 --- Documentation/config.txt | 4 ++ builtin/receive-pack.c | 111 +

[PATCH v3 27/28] clone: use git protocol for cloning shallow repo locally

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 check_everything_conne

[PATCH v3 21/28] send-pack: support pushing to a shallow clone

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

[PATCH v3 25/28] send-pack: support pushing from a shallow clone via http

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

[PATCH v3 15/28] fetch: add --update-shallow to get refs that require updating .git/shallow

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/fetch-options.txt | 6 ++ builtin/fetch.c | 6 +- fetch-pack.c| 26 ++ fetch-pack.h| 1 + t/t5536-fetch-shallow.sh| 22 ++

[PATCH v3 16/28] receive-pack: reorder some code in unpack()

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 --- bui

[PATCH v3 09/28] shallow.c: extend setup_*_shallow() to accept extra shallow points

Signed-off-by: Nguyễn Thái Ngọc Duy --- 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 --- a/commit.h +++ b/c

[PATCH v3 18/28] New var GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses

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 s

[PATCH v3 14/28] upload-pack: make sure deepening preserves shallow roots

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 c

[PATCH v3 08/28] shallow.c: add mark_new_shallow_refs()

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 again

[PATCH v3 10/28] fetch-pack.c: move shallow update code out of fetch_pack()

Signed-off-by: Nguyễn Thái Ngọc Duy --- 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 remove_duplicates_in_re

[PATCH v3 11/28] fetch-pack.h: one statement per bitfield declaration

Signed-off-by: Nguyễn Thái Ngọc Duy --- 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 fetch_pack_args { c

[PATCH v3 17/28] Support pushing from a shallow clone

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 upstre

[PATCH v3 13/28] fetch: support fetching from a shallow repository

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,

[PATCH v3 12/28] clone: support remote shallow repository

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 probably

[PATCH v3 05/28] Advertise shallow graft information on the server end

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 s

[PATCH v3 03/28] clone: prevent --reference to a shallow repository

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 $GIT_DIR/sha

[PATCH v3 02/28] send-pack: forbid pushing from a shallow repository

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 lear

[PATCH v3 06/28] connect.c: teach get_remote_heads to parse "shallow" lines

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 --- builtin/fetch-pack.c | 2 +- builtin/send-pack.c | 2 +- connect.c| 12 +++- r

[PATCH v3 01/28] transport.h: remove send_pack prototype, already defined in send-pack.h

Signed-off-by: Nguyễn Thái Ngọc Duy --- 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, struct ref *refs, t

[PATCH v3 07/28] shallow.c: add remove_reachable_shallow_points()

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 th

[PATCH v3 04/28] update-server-info: do not publish shallow clones

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 --- server-info.c | 9 + 1 file changed, 9 insertions(+) diff --git a/server-info.c b/server-info.

[PATCH v3 00/28] First class shallow clone

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

Re: gettext CTYPE for libc

On 24/11/2013 16:05, Thomas Rast wrote: > Trần Ngọc Quân 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" for

Re: error: git-remote-https died of signal 13

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 (a

Re: error: git-remote-https died of signal 13

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 proble

Re: [PATCH v3 10/21] pack-bitmap: add support for bitmap indexes

Jeff King 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 > + > + Pe

Re: slow git-cherry-pick.

On Sunday 24 of November 2013 19:47:10 Duy Nguyen wrote: > On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora 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 installa

Re: error: git-remote-https died of signal 13

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

Re: Git issues with submodules

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 ab

Re: error: git-remote-https died of signal 13

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 pro

Re: error: git-remote-https died of signal 13

[+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 clo

Re: error: git-remote-https died of signal 13

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

Re: error: git-remote-https died of signal 13

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 connectivit

Re: error: git-remote-https died of signal 13

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)

Re: slow git-cherry-pick.

On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora 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 > (few seconds per cher

Re: slow git-cherry-pick.

On Sun, Nov 24, 2013 at 7:47 PM, Duy Nguyen wrote: > On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora 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 wit

slow git-cherry-pick.

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 re

Re: [PATCH] drop support for "experimental" loose objects

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

Re: gettext CTYPE for libc

Trần Ngọc Quân 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 gettext.c, it

Re: [PATCH] drop support for "experimental" loose objects

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 t

Re: [PATCH] git-svn: Support svn:global-ignores property

Hi Aleksey Thanks for your patch. I added Eric Wong to the Cc list; all git-svn patches should go to him. Aleksey Vasenev writes: > --- Can you write a commit message? If you need a guideline for what to write there, consider this snippet from Documentation/SubmittingPatches: The body sho