Re: [PATCH] status: hint the user about -uno if read_directory takes too long

2013-03-16 Thread Torsten Bögershausen
On 15.03.13 22:59, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: Thanks, that looks good to me: # It took 2.58 seconds to enumerate untracked files. # Consider the -u option for a possible speed-up? But: If I follow the advice as is given and use git status -u, the

Re: Tag peeling peculiarities

2013-03-16 Thread Michael Haggerty
On 03/14/2013 02:40 PM, Jeff King wrote: Hmph. I coincidentally ran across another problem with 435c833 today. Try this: [...] But that's somewhat off-topic for this discussion. I'll look into it further and try to make a patch later today or tomorrow. On Thu, Mar 14, 2013 at 12:28:53PM

[PATCH 0/2] peel-ref optimization fixes

2013-03-16 Thread Jeff King
These patches fix the issue with peel-ref noticed recently by Michael (namely that we fail to correctly peel packed refs outside of refs/tags). The problem has been there since we added peeling support to pack-refs, but traditionally show-ref -d was the only caller that actually triggered the

[PATCH 1/2] pack-refs: write peeled entry for non-tags

2013-03-16 Thread Jeff King
When we pack an annotated tag ref, we write not only the sha1 of the tag object along with the ref, but also the sha1 obtained by peeling the tag. This lets readers of the pack-refs file know the peeled value without having to actually load the object, speeding up upload-pack's ref advertisement.

[PATCH 2/2] pack-refs: add fully-peeled trait

2013-03-16 Thread Jeff King
Older versions of pack-refs did not write peel lines for refs outside of refs/tags. This meant that on reading the pack-refs file, we might set the REF_KNOWS_PEELED flag for such a ref, even though we do not know anything about its peeled value. The previous commit updated the writer to always

Re: [PATCH 11/12] pretty: support truncating in %, % and %

2013-03-16 Thread Paul Campbell
On Sat, Mar 16, 2013 at 2:24 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: %(N,trunc) truncates the righ part after N columns and replace the last two letters with ... ltrunc does the same on the left. mtrunc cuts the middle out. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com ---

Re: Tag peeling peculiarities

2013-03-16 Thread Jeff King
On Sat, Mar 16, 2013 at 09:48:42AM +0100, Michael Haggerty wrote: My patch series is nearly done. I will need another day or two to review and make it submission-ready, but I wanted to give you an idea of what I'm up to and I could also use your feedback on some points. I was just sending

Some small issues with GIT GUI on MacOS.

2013-03-16 Thread Pascal
Hello, I'm new to this list and using GIT on MacOS 10.8: $ /usr/local/git/bin/git --version git version 1.7.4.1 I've caught some small issues when using GIT GUI (French version): - when GIT GUI just launched, the menu Dépôt (repository I guess) and Apple are disabled - when opening preferences

[PATCH 0/3] fix unparsed object access in upload-pack

2013-03-16 Thread Jeff King
This series fixes the issue I mentioned recently with upload-pack, where we might feed unparsed objects to the revision parser. The bug is in 435c833 (the tip of the jk/peel-ref topic), which is in v1.8.1 and up. The fix should go to maint. The bug breaks shallow clones from repositories with

[PATCH 1/3] upload-pack: drop lookup-before-parse optimization

2013-03-16 Thread Jeff King
When we receive a have line from the client, we want to load the object pointed to by the sha1. However, we are careful to do: o = lookup_object(sha1); if (!o || !o-parsed) o = parse_object(sha1); to avoid loading the object from disk if we have already seen it. However, since

[PATCH 2/3] upload-pack: make sure want objects are parsed

2013-03-16 Thread Jeff King
When upload-pack receives a want line from the client, it adds it to an object array. We call lookup_object to find the actual object, which will only check for objects already in memory. This works because we are expecting to find objects that we already loaded during the ref advertisement. We

[PATCH 3/3] upload-pack: load non-tip want objects from disk

2013-03-16 Thread Jeff King
It is a long-time security feature that upload-pack will not serve any want lines that do not correspond to the tip of one of our refs. Traditionally, this was enforced by checking the objects in the in-memory hash; they should have been loaded and received the OUR_REF flag during the

Re: regression in multi-threaded git-pack-index

2013-03-16 Thread Jeff King
On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote: We have uncovered a regression in this commit: b8a2486f1524947f232f657e9f2ebf44e3e7a243 The symptom is that 'git fetch' dies with: error: index-pack died of signal 10 fatal: index-pack failed I have only been able to

Re: [PATCH/RFC] http_init: only initialize SSL for https

2013-03-16 Thread Jeff King
On Fri, Mar 15, 2013 at 05:23:27PM +0100, Daniel Stenberg wrote: Thanks, then we should stick to starting from ALL like everybody else who followed the suggestion in the documentation. Do you have recommendations on the conditional dropping of SSL? Not really, no. SSL initing is as has

Re: regression in multi-threaded git-pack-index

2013-03-16 Thread Duy Nguyen
On Sat, Mar 16, 2013 at 6:41 PM, Jeff King p...@peff.net wrote: On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote: We have uncovered a regression in this commit: b8a2486f1524947f232f657e9f2ebf44e3e7a243 What version did you test? We used to have problems with multithreaded

Re: SSH version on Git 1.8.1.2 for Windows is outdated.

2013-03-16 Thread Sebastian Schuberth
On 15.03.2013 21:11, Joshua Jensen wrote: Yes, you should grab the msysGit (the Git for Windows build environment) [2], tweak it to include the new OpenSSH binary, ensure it builds and works OK and then send a pull request (or post your patchset to the msysgit mailing list [3]. Wow, we can do

Re: Tag peeling peculiarities

2013-03-16 Thread Michael Haggerty
On 03/16/2013 10:34 AM, Jeff King wrote: On Sat, Mar 16, 2013 at 09:48:42AM +0100, Michael Haggerty wrote: My patch series is nearly done. I will need another day or two to review and make it submission-ready, but I wanted to give you an idea of what I'm up to and I could also use your

Re: [PATCH 1/2] pack-refs: write peeled entry for non-tags

2013-03-16 Thread Michael Haggerty
Looks good aside from a couple of minor points mentioned below. On 03/16/2013 10:01 AM, Jeff King wrote: When we pack an annotated tag ref, we write not only the sha1 of the tag object along with the ref, but also the sha1 obtained by peeling the tag. This lets readers of the pack-refs file

Re: [PATCH 2/2] pack-refs: add fully-peeled trait

2013-03-16 Thread Michael Haggerty
ACK, with one ignorable comment. Michael On 03/16/2013 10:01 AM, Jeff King wrote: Older versions of pack-refs did not write peel lines for refs outside of refs/tags. This meant that on reading the pack-refs file, we might set the REF_KNOWS_PEELED flag for such a ref, even though we do not

Re: git svn error Not a valid object name

2013-03-16 Thread Thomas Rast
[+Cc Eric] Adam Retter a...@exist-db.org writes: $ git svn init -t tags -b stable -T trunk file:///home/ec2-user/svn-rsync/code new-git-repo $ cd new-git-repo $ git config svn-remote.svn.preserve-empty-dirs true $ git config svn-remote.svn.rewriteRoot https://svn.code.sf.net/p/exist/code $

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

2013-03-16 Thread Thomas Rast
Junio C Hamano gits...@pobox.com writes: Karsten Blees karsten.bl...@gmail.com writes: However, AFAIK inotify doesn't work recursively, so the daemon would at least have to track the directory structure to be able to register / unregister inotify handlers as directories come and go. Yes,

[PATCH] Makefile: keep LIB_H entries together and sorted

2013-03-16 Thread René Scharfe
As a follow-up to 60d24dd25 (Makefile: fold XDIFF_H and VCSSVN_H into LIB_H), let the unconditional additions to LIB_H form a single sorted list. Also drop the duplicate entry for xdiff/xdiff.h, which was easy to spot after sorting. Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx ---

Re: git svn error Not a valid object name

2013-03-16 Thread Eric Wong
Adam Retter a...@exist-db.org wrote: If your able, any idea of when you might be able to take a look at the bug? Our svn repo is publicly available for all. svn ls https://svn.code.sf.net/p/exist/code/trunk ...Is asking me for username -- To unsubscribe from this list: send the line unsubscribe

[PATCH] advice: Remove unused advice_push_non_ff_default

2013-03-16 Thread Ramsay Jones
Commit 27f76a2b ('push: switch default from matching to simple', 04-01-2013) removed the last use of the 'advice_push_non_ff_default' variable, along with the advice message which it used to suppress. Remove the 'advice_push_non_ff_default' variable definition, along with the now redundant

[PATCH] sha1_name: pass object name length to diagnose_invalid_sha1_path()

2013-03-16 Thread René Scharfe
The only caller of diagnose_invalid_sha1_path() extracts a substring from an object name by creating a NUL-terminated copy of the interesting part. Add a length parameter to the function and thus avoid the need for an allocation, thereby simplifying the code. Signed-off-by: Rene Scharfe

Re: git svn error Not a valid object name

2013-03-16 Thread Dannes Wessels
Http:// should provide access without password .. -- Dannes Wessels On 16 mrt. 2013, at 18:13, Eric Wong normalper...@yhbt.net wrote: Adam Retter a...@exist-db.org wrote: If your able, any idea of when you might be able to take a look at the bug? Our svn repo is publicly available for

Re: git svn error Not a valid object name

2013-03-16 Thread Adam Retter
Ah right yes, sorry the HTTPS version needs a username the HTTP version does not. Please use: http://svn.code.sf.net/p/exist/code On 16 March 2013 17:13, Eric Wong normalper...@yhbt.net wrote: Adam Retter a...@exist-db.org wrote: If your able, any idea of when you might be able to take a look

[PATCH] rev-parse: Clarify documentation of @{upstream} syntax

2013-03-16 Thread Kacper Kornet
git-rev-parse interprets string in string@{upstream} as a name of a branch not a ref. For example refs/heads/master@{upstream} looks for an upstream branch that is merged by git-pull to ref refs/heads/refs/heads/master not to refs/heads/master. However the documentation could misled a user to

[PATCH] safe_create_leading_directories: fix race that could give a false negative

2013-03-16 Thread Steven Walter
If two processes are racing to create the same directory tree, they will both see that the directory doesn't exist, both try to mkdir(), and one of them will fail. This is okay, as we only care that the directory gets created. So, we add a check for EEXIST from mkdir, and continue if the

[PATCH] gitk: Add user-configurable branch bg color

2013-03-16 Thread Manuel Bua
In some cases, the default branch background color (green) isn't an optimal choice, thus it can be difficult to read. This provides a way for the user to customize the color used to fill the rectangle around the branch name, by choosing another one from the Preferences dialog. The default

Re: SSH version on Git 1.8.1.2 for Windows is outdated.

2013-03-16 Thread Sebastian Schuberth
On Sat, Mar 16, 2013 at 9:49 PM, Patrik Gornicz patrik-...@mail.pgornicz.com wrote: Any idea as to when this mingwGitDevEnv project will be mature enough to use as a replacement for msysgit? One of the reasons I gave up trying to tweak Due to a lack of contributors this is taking longer than I

Re: SSH version on Git 1.8.1.2 for Windows is outdated.

2013-03-16 Thread Patrik Gornicz
On 03/16/13 09:14, Sebastian Schuberth wrote: On 15.03.2013 21:11, Joshua Jensen wrote: Yes, you should grab the msysGit (the Git for Windows build environment) [2], tweak it to include the new OpenSSH binary, ensure it builds and works OK and then send a pull request (or post your patchset

Re: [PATCH/RFC] http_init: only initialize SSL for https

2013-03-16 Thread Daniel Stenberg
On Sat, 16 Mar 2013, Jeff King wrote: But are we correct in assuming that curl will barf if it gets a redirect to an ssl-enabled protocol? My testing seems to say yes: Ah yes. If it switches over to an SSL-based protocol it will pretty much require that it had been initialized previously.

Re: [RFC/PATCH] Introduce remote.pushdefault

2013-03-16 Thread Ramkumar Ramachandra
Sorry about the horribly late response- I just got around to re-rolling this, and had a doubt. Junio C Hamano gits...@pobox.com wrote: Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/Documentation/config.txt b/Documentation/config.txt index 9b11597..82a4a78 100644 ---

Re: [BUG?] google code http auth weirdness

2013-03-16 Thread Shawn Pearce
On Fri, Mar 15, 2013 at 4:59 AM, Jeff King p...@peff.net wrote: I tried pushing to a repository at Google Code for the first time today, and I encountered some weird behavior with respect to asking for credentials. If I use the url https://code.google.com/r/repo/;, everything works; I get

experimenting with JGit and bitmaps

2013-03-16 Thread Shawn Pearce
JGit has merged the bitmap work Colby and I were working on[1] and plans to ship it in JGit 2.4. The bitmaps are now stored in a separate .bitmap file alongside of a pack, making the entire system backward-compatible with git-core. If you have Java and Maven installed you can try this out

Re: [BUG?] google code http auth weirdness

2013-03-16 Thread Jeff King
On Sat, Mar 16, 2013 at 06:11:32PM -0700, Shawn O. Pearce wrote: That seems kind of crazy to me. It's generating an HTTP 200 just to tell us the credentials are wrong. Which kind of makes sense; it's the only way to convince the git client to show a custom message when it aborts (rather

[PATCH] Preallocate hash tables when the number of inserts are known in advance

2013-03-16 Thread Nguyễn Thái Ngọc Duy
This avoids unnecessary re-allocations and reinsertions. On webkit.git (i.e. about 182k inserts to the name hash table), this reduces about 100ms out of 3s user time. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- nd/read-directory-recursive-optim reduces the number of input (from

Re: [PATCH] rev-parse: Clarify documentation of @{upstream} syntax

2013-03-16 Thread Eric Sunshine
On Sat, Mar 16, 2013 at 2:51 PM, Kacper Kornet drae...@pld-linux.org wrote: git-rev-parse interprets string in string@{upstream} as a name of a branch not a ref. For example refs/heads/master@{upstream} looks for an upstream branch that is merged by git-pull to ref refs/heads/refs/heads/master

Re: [PATCH] status: hint the user about -uno if read_directory takes too long

2013-03-16 Thread Junio C Hamano
Torsten Bögershausen tbo...@web.de writes: Or we can be more explicit and say # It took 2.58 seconds to search for untracked files. 'status -uno' # may speed it up, but you have to be careful not to forget to add # new files yourself (see 'git help status'). Thanks, that looks good for

Re: [PATCH] pull: Apply -q and -v options to rebase mode as well

2013-03-16 Thread Junio C Hamano
Peter Eisentraut pe...@eisentraut.org writes: git pull passed -q and -v only to git merge, but they can be useful for git rebase as well, so pass them there, too. In particular, using -q shuts up the Already up-to-date. message. Add test cases to prove it. Signed-off-by: Peter Eisentraut

Re: [PATCH v1 22/45] archive: convert to use parse_pathspec

2013-03-16 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: On Sat, Mar 16, 2013 at 12:56 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: @@ -232,11 +228,18 @@ static int path_exists(struct tree *tree, const char *path) static void parse_pathspec_arg(const char

Re: [PATCH 0/3] fix unparsed object access in upload-pack

2013-03-16 Thread Junio C Hamano
Jeff King p...@peff.net writes: This series fixes the issue I mentioned recently with upload-pack, where we might feed unparsed objects to the revision parser. The bug is in 435c833 (the tip of the jk/peel-ref topic), which is in v1.8.1 and up. Good to see follow-up from a responsible

Re: [PATCH v1 22/45] archive: convert to use parse_pathspec

2013-03-16 Thread Duy Nguyen
On Sun, Mar 17, 2013 at 12:00 PM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Sat, Mar 16, 2013 at 12:56 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: @@ -232,11 +228,18 @@ static int path_exists(struct tree

Re: [PATCH] Preallocate hash tables when the number of inserts are known in advance

2013-03-16 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This avoids unnecessary re-allocations and reinsertions. On webkit.git (i.e. about 182k inserts to the name hash table), this reduces about 100ms out of 3s user time. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com I think this is a very

Re: [PATCH] Preallocate hash tables when the number of inserts are known in advance

2013-03-16 Thread Duy Nguyen
On Sun, Mar 17, 2013 at 12:34 PM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This avoids unnecessary re-allocations and reinsertions. On webkit.git (i.e. about 182k inserts to the name hash table), this reduces about 100ms out of 3s user time.

Re: [PATCH 0/3] fix unparsed object access in upload-pack

2013-03-16 Thread Jeff King
On Sat, Mar 16, 2013 at 10:16:40PM -0700, Junio C Hamano wrote: ... (I had several bug reports within a few hours of deploying v1.8.1.5 on github.com) Nice to have a pro at the widely used site ;-) I often wish it had a mechanism to deploy the tip of 'master' or 'maint', or even 'next'

Re: [RFC/PATCH] Introduce remote.pushdefault

2013-03-16 Thread Jeff King
On Sun, Mar 17, 2013 at 06:00:08AM +0530, Ramkumar Ramachandra wrote: +remote.pushdefault:: + The remote to push to by default. Overrides the + branch-specific configuration `branch.name.remote`. It feels unexpected to see I may have said while on this branch I push there and

Re: [PATCH 2/2] pack-refs: add fully-peeled trait

2013-03-16 Thread Junio C Hamano
Jeff King p...@peff.net writes: The simplest fix would be to always unset the REF_KNOWS_PEELED flag for refs outside of refs/tags that do not have a peel line (if it has a peel line, we know it is valid, but we cannot assume a missing peel line means anything). But that loses an important

Re: [PATCH 2/2] pack-refs: add fully-peeled trait

2013-03-16 Thread Jeff King
On Sat, Mar 16, 2013 at 10:50:17PM -0700, Junio C Hamano wrote: I however wonder if the above implies it may make sense to add this on top? Perhaps it is not worth it, because it makes a difference only to a repository with annotated tags outside refs/tags hierarchy and still has the