[PATCH 1/2] sha1_object_info_extended: provide delta base sha1s

2013-12-21 Thread Jeff King
than simply returning random bytes). Signed-off-by: Jeff King p...@peff.net --- cache.h | 1 + sha1_file.c | 53 + 2 files changed, 54 insertions(+) diff --git a/cache.h b/cache.h index ce377e1..67356db 100644 --- a/cache.h +++ b/cache.h

[PATCH 0/2] cat-file --batch-check='%(deltabase)'

2013-12-21 Thread Jeff King
This series lets you query the delta base for a particular object (or set of objects), like: $ git rev-list --objects --all | git cat-file --batch-check='%(objectname) %(deltabase) %(rest)' The only other way I know of to get this information is using verify-pack (or index-pack), which is

[PATCH 2/2] cat-file: provide %(deltabase) batch format

2013-12-21 Thread Jeff King
format, which makes it fast and simple to get the bases for a subset of the objects. Signed-off-by: Jeff King p...@peff.net --- Documentation/git-cat-file.txt | 12 +--- builtin/cat-file.c | 6 ++ t/t1006-cat-file.sh| 34 ++ 3 files

[PATCH 0/3] t0000 cleanups

2013-12-28 Thread Jeff King
When I want to debug a failing test, I often end up doing: cd t ./t4107-tab -v -i cd tratab The test names are long, so tab-completing on the trash directory is very helpful. Lately I've noticed that there are a bunch of crufty trash directories in my t/ directory, which makes my

[PATCH 2/3] t0000: simplify HARNESS_ACTIVE hack

2013-12-28 Thread Jeff King
a harness. Signed-off-by: Jeff King p...@peff.net --- I do not have any plans to write such tests, and I'd be OK if we wanted to stop this just at fixing up the comments. But it took me a while to figure out what is going on, and I believe unsetting HARNESS_ACTIVE in the sub-tests is the choice

[PATCH 3/3] t0000: drop known breakage test

2013-12-28 Thread Jeff King
suite is truly broken, since it is not a test-within-a-test, as the later tests are. Signed-off-by: Jeff King p...@peff.net --- I am not _that_ bothered by the known breakage, but AFAICT there is zero benefit to keeping this redundant test. But maybe I am missing something. t/t-basic.sh | 3

Re: git:// protocol over SSL/TLS

2013-12-28 Thread Jeff King
On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote: The web server software has nothing to do with HTTP[S] used by Git being smart, I think, it just has to be set up properly. Misunderstood git doc then which says it has to be Apache, currently - other CGI servers don't work,

Re: [PATCH 02/12] Convert starts_with() to skip_prefix() for option parsing

2013-12-28 Thread Jeff King
On Thu, Dec 26, 2013 at 11:27:10AM -0800, Junio C Hamano wrote: I still need consensus on the name here guys, parse_prefix. remove_prefix or strip_prefix? If no other opinions i'll go with strip_prefix (Jeff's comment before parse_prefix() also uses strip) Yup, that comment is where I

Re: [PATCH 1/3] t0000: set TEST_OUTPUT_DIRECTORY for sub-tests

2013-12-28 Thread Jeff King
On Sat, Dec 28, 2013 at 02:13:13PM -0800, Jonathan Nieder wrote: So the idea if I am reading correctly is Instead of relying on the implicit output directory chosen with chdir, which doesn't even work any more, set TEST_OUTPUT_DIRECTORY to decide where output for the sub-tests used by t's

Re: [PATCH 3/3] t0000: drop known breakage test

2013-12-28 Thread Jeff King
On Sat, Dec 28, 2013 at 12:51:04PM -0800, Jonathan Nieder wrote: Jeff King wrote: I am not _that_ bothered by the known breakage, but AFAICT there is zero benefit to keeping this redundant test. Devil's advocate: it ensures that anyone wrapping git's tests (like the old smoketest

Re: Fwd: Runaway git remote if group definition contains a remote by the same name

2013-12-28 Thread Jeff King
On Sat, Dec 28, 2013 at 03:56:55PM +0100, Alex Riesen wrote: it is also a way to create a fork bomb out of the innocent tool on platforms where pressing Ctrl-C does not terminate subprocesses of the foreground process (like, of course, Windows). To reproduce, run git -c

Re: Fwd: Runaway git remote if group definition contains a remote by the same name

2013-12-31 Thread Jeff King
On Mon, Dec 30, 2013 at 11:10:31AM -0800, Junio C Hamano wrote: So I think the sanest thing is probably: 1. Teach fetch to expand recursively in a single process, and then tell sub-processes (via a new command-line option) not to expand any further. 2. Teach fetch to

Re: [PATCH 0/3] t0000 cleanups

2013-12-31 Thread Jeff King
On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote: I think it can be better, since the commit message left me scratching my head while the patch itself seems pretty simple. How about something like the following? I am fine with that format, though... Analysis and fix:

Re: [PATCH] drop unnecessary copying in credential_ask_one

2014-01-01 Thread Jeff King
smarter git_terminal_prompt wrapper), and sometimes it returns an allocated string from do_askpass. Signed-off-by: Jeff King p...@peff.net --- prompt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/prompt.c b/prompt.c index d851807..d7bb17c 100644 --- a/prompt.c +++ b

Re: [PATCH] drop unnecessary copying in credential_ask_one

2014-01-01 Thread Jeff King
On Wed, Jan 01, 2014 at 10:03:30PM -0500, Jeff King wrote: On Thu, Jan 02, 2014 at 09:06:33AM +0800, Tay Ray Chuan wrote: We were leaking memory in there, as after obtaining a string from git_getpass, we returned a copy of it, yet no one else held the original string, apart from

Re: [PATCH v2 3/4] Speed up is_git_command() by checking early for internal commands

2014-01-03 Thread Jeff King
On Thu, Jan 02, 2014 at 11:41:05AM -0800, Junio C Hamano wrote: - builtin/merge.c is the same, but it is conceptually even worse. It has the end-user supplied string and wants to see if it is a valid strategy. If the user wants to use a custom strategy, a single stat() to make sure

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Sun, Dec 22, 2013 at 09:55:23PM +, Ben Maurer wrote: One issue with this approach is that it seems git-pack-index doesn't perform as well with thin packs. git-index-pack uses a multi-threaded approach to resolving the deltas. However, the multithreading only works on deltas that are

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Sun, Dec 22, 2013 at 11:47:34AM -0800, Ben Maurer wrote: Jeff King's bitmap branch appears to give a very substantial speedup. After applying this branch, the counting objects phase is basically free. However, I found that the compression phase still takes a non-trivial amount of time.

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote: I was going to ask you to send your repository, but I can easily reproduce here. I guess people don't run into it because it's uncommon to fetch the whole refs/ namespace from a non-bare repo (and bare repos do not tend to

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 08:37:49AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: We could probably teach index-pack an --assume-refs-are-thin option to optimize for this case, and have fetch-pack/receive-pack pass it whenever they know that delta-base-offset was negotiated

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote: Unless you set @{u} to this new configuration, in which case the choice becomes dynamic depending on the current branch, but - if that is the only sane choice based on the current branch, why not use that as the default

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 09:57:23AM -0500, Jeff King wrote: diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index c733379..0cff874 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1402,6 +1402,19 @@ static void check_object(struct object_entry *entry

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote: Yeah, I had similar thoughts. I personally use branch.*.merge as forkedFrom, and it seems like we are going that way anyway with things like git rebase and git merge defaulting to upstream. But then there is git push -u and

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote: I wonder if it is too late to try to clarify this dual usage. It kind of seems like the push config is this is the place I publish to. Which, in many workflows, just so happens to be the exact same as the place you forked

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 09:15:04PM +, Ben Maurer wrote: Let me know how this patch does for you. My testing has been fairly limited so far. This patch looks like a much cleaner version :-). Works well for me, but my test setup may not be great since I didn't get any errors from

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 12:17:21PM -0800, Junio C Hamano wrote: I am fine with rejecting it with a warning, but we should not then complain that the other side did not send us the object, since we should not be asking for it at all. I also do not see us complaining about the funny ref

Re: [PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

2014-01-07 Thread Jeff King
On Mon, Jan 06, 2014 at 07:35:04PM -0800, Brodie Rao wrote: On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao bro...@sf.io wrote: This change ensures get_sha1_basic() doesn't try to resolve full hashes as refs when ambiguous ref warnings are disabled. This provides a substantial performance

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-07 Thread Jeff King
On Mon, Jan 06, 2014 at 10:14:30PM +, Ben Maurer wrote: It looks like for my repo the size win wasn't as big (~10%). Is it possible that with the kernel test you got extremely lucky and there was some huge binary blob that thin packing turned into a tiny delta? I don't think so. When I

Re: [PATCH] drop unnecessary copying in credential_ask_one

2014-01-07 Thread Jeff King
On Thu, Jan 02, 2014 at 11:08:51AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: ... But the test suite, of course, always uses askpass because it cannot rely on accessing a terminal (we'd have to do some magic with lib-terminal, I think). So it doesn't detect

Re: [PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 09:51:07AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: Alternatively, I guess cat-file --batch could just turn off warn_ambiguous_refs itself. Sounds like a sensible way to go, perhaps on top of this change? The downside is that we would

Re: [PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 11:38:15AM -0800, Junio C Hamano wrote: Alternatively, I guess cat-file --batch could just turn off warn_ambiguous_refs itself. Sounds like a sensible way to go, perhaps on top of this change? The downside is that we would not warn about ambiguous refs

Re: [PATCH] drop unnecessary copying in credential_ask_one

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 11:44:00AM -0800, Junio C Hamano wrote: test-terminal only handles stdout and stderr streams as fake terminals. We could pretty easily add stdin for input, as it uses fork() to work asynchronously. But the credential code does not actually read from stdin. It

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Jeff King
isn't specified. To tackle this problem, introduce branch.*.forkedFrom which can specify the parent branch of a topic branch. Future patches will build functionality around this new configuration variable. Cc: Jeff King p...@peff.net Cc: Junio C Hamano gis...@pobox.com Signed-off

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 03:40:56AM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: Yeah, I had similar thoughts. I personally use branch.*.merge as forkedFrom, and it seems like we are going that way anyway with things like git rebase and git merge defaulting to upstream. My issue

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote: Junio C Hamano wrote:. As I said in the different subthread, I am not convinced that you would need the complexity of branch.*.forkedFrom. If you set your upstream to the true upstream (not your publishing point), and

Re: [RFC/PATCH] format-patch: introduce branch.*.forkedFrom

2014-01-07 Thread Jeff King
On Wed, Jan 08, 2014 at 02:32:10AM +0530, Ramkumar Ramachandra wrote: we should leave @{upstream} as (1), and add a new option to represent (2). Not the other way around. I have a local branch 'forkedfrom' that has two sources: 'master' and 'ram/forkedfrom'. 'ram/forkedfrom' isn't a dumb

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 01:07:08PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: Yes, pushbranch is probably a better name for what I am referring to. I agree that pushremote is probably enough for sane cases. I seem to recall that people advocating the upstream push

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Jeff King
On Wed, Jan 08, 2014 at 02:55:04AM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: My daily procedure is something like: all_topics | while read topic; do echo $topic $(git rev-parse $topic@{u}); done | topo_sort | while read topic upstream; do git rebase $upstream

Re: [PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 12:31:57PM -0800, Junio C Hamano wrote: c. Just leave it at Brodie's patch with nothing else on top. My thinking in favor of (b) was basically does anybody actually care about ambiguous refs in this situation anyway?. If they do, then I think (c) is my

[PATCH 2/4] cat-file: fix a minor memory leak in batch_objects

2014-01-07 Thread Jeff King
We should always have been freeing our strbuf, but doing so consistently was annoying until the refactoring in the previous patch. Signed-off-by: Jeff King p...@peff.net --- builtin/cat-file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/cat-file.c b/builtin/cat-file.c index

[PATCH 3/4] cat-file: restore ambiguity warning flag in batch_objects

2014-01-07 Thread Jeff King
. Signed-off-by: Jeff King p...@peff.net --- builtin/cat-file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/cat-file.c b/builtin/cat-file.c index ce79103..c64e287 100644 --- a/builtin/cat-file.c +++ b/builtin/cat-file.c @@ -264,6 +264,7 @@ static int batch_objects(struct

[PATCH 1/4] cat-file: refactor error handling of batch_objects

2014-01-07 Thread Jeff King
This just pulls the return value for the function out of the inner loop, so we can break out of the loop rather than do an early return. This will make it easier to put any cleanup for the function in one place. Signed-off-by: Jeff King p...@peff.net --- Just making the subsequent diffs less

[PATCH 4/4] revision: turn off object/refname ambiguity check for --stdin

2014-01-07 Thread Jeff King
=raw real0m0.675s user0m0.552s sys 0m0.120s [after] $ best-of-five -i commits ./git rev-list --stdin --no-walk --pretty=raw real0m0.415s user0m0.400s sys 0m0.012s Signed-off-by: Jeff King p...@peff.net --- Obviously we drop this one (and revert 25fba78d

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: I think that is sensible, and only heightens my sense of the upstream push.default as useless. :) Yes, it only is good for centralized world (it was designed back in the centralized days

[PATCH v2] speeding up 40-hex ambiguity check

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 05:08:56PM -0500, Jeff King wrote: OK. I agree with that line of thinking. Let's take it one step at a time, i.e. do c. and also use warn_on_object_refname_ambiguity in rev-list --stdin first and leave the simplification (i.e. b.) for later. Here's a series

[PATCH v2 2/5] cat-file: fix a minor memory leak in batch_objects

2014-01-07 Thread Jeff King
We should always have been freeing our strbuf, but doing so consistently was annoying until the refactoring in the previous patch. Signed-off-by: Jeff King p...@peff.net --- builtin/cat-file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/cat-file.c b/builtin/cat-file.c index

[PATCH v2 1/5] cat-file: refactor error handling of batch_objects

2014-01-07 Thread Jeff King
This just pulls the return value for the function out of the inner loop, so we can break out of the loop rather than do an early return. This will make it easier to put any cleanup for the function in one place. Signed-off-by: Jeff King p...@peff.net --- builtin/cat-file.c | 11 +-- 1

[PATCH v2 3/5] refs: teach for_each_ref a flag to avoid recursion

2014-01-07 Thread Jeff King
namespace, and make it available at both sites. This is simple, and given that we do not have a proliferation of flags (we have had exactly one until now), it is probably sufficient. Signed-off-by: Jeff King p...@peff.net --- I think the flags thing is OK as explained above, but Michael may have

[PATCH v2 5/5] get_sha1: drop object/refname ambiguity flag

2014-01-07 Thread Jeff King
, with speedup] $ best-of-five -i objects ./git cat-file --batch-check real0m0.388s user0m0.356s sys 0m0.028s So the new implementation does just as well as we did with the flag turning the whole thing off (better actually, but that is within the noise). Signed-off-by: Jeff

[PATCH v2 4/5] get_sha1: speed up ambiguous 40-hex test

2014-01-07 Thread Jeff King
is much lower, as we are avoiding hundreds of thousands of stat() calls. Signed-off-by: Jeff King p...@peff.net --- I wanted to make the ref traversal as cheap as possible, hence the NO_RECURSE flag I added. I thought INCLUDE_BROKEN used to not open up the refs at all, but it looks like it does

[PATCH v3 3/5] refs: teach for_each_ref a flag to avoid recursion

2014-01-07 Thread Jeff King
On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote: + if (flags DO_FOR_EACH_NO_RECURSE) { + struct ref_dir *subdir = get_ref_dir(entry); + sort_ref_dir(subdir); + retval

Re: It seems there is a very tight character count limit in .gitconfig

2014-01-07 Thread Jeff King
On Wed, Jan 08, 2014 at 02:59:37PM +0800, Li Zhang wrote: I tried to add url xxx insteadof xxx in .gitconfig. If the length of url exceed 125, git will not work. I am using Ubuntu. The default version is 1.7.9.5. Maybe the latest version solve this already. Yes, this was fixed in 0971e99

[RFC/PATCH 0/5] branch@{publish} shorthand

2014-01-08 Thread Jeff King
On Wed, Jan 08, 2014 at 03:05:48AM +0530, Ramkumar Ramachandra wrote: Agreed. I'll start working on @{publish}. It's going to take quite a bit of effort, because I won't actually start using it until my prompt is @{publish}-aware. There's a fair bit of refactoring involved. I took a stab at

[PATCH 1/5] sha1_name: refactor upstream_mark

2014-01-08 Thread Jeff King
We will be adding new mark types in the future, so separate the suffix data from the logic. Signed-off-by: Jeff King p...@peff.net --- sha1_name.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index b1873d8..0c50801 100644

[PATCH 3/5] branch_get: return early on error

2014-01-08 Thread Jeff King
Right now we simply check if ret is valid before doing further processing. As we add more processing, this will become more and more cumbersome. Instead, let's just check whether ret is invalid and return early with the error. Signed-off-by: Jeff King p...@peff.net --- remote.c | 5 - 1 file

[PATCH 4/5] branch_get: provide per-branch pushremote pointers

2014-01-08 Thread Jeff King
we store separately as pushremote_config_default. We can then set the branch's pushremote field by doing the normal sequence of config fallback. Signed-off-by: Jeff King p...@peff.net --- remote.c | 23 +++ remote.h | 2 ++ 2 files changed, 21 insertions(+), 4 deletions

[PATCH 2/5] interpret_branch_name: factor out upstream handling

2014-01-08 Thread Jeff King
simpler to add more constructs in future patches. While we're at it, let's also break apart the refactored code into a few helper functions. These will be useful when we implement similar @{upstream}-like constructs. Signed-off-by: Jeff King p...@peff.net --- sha1_name.c | 83

[PATCH 5/5] implement @{publish} shorthand

2014-01-08 Thread Jeff King
an example: $ git checkout -b foo origin/master $ git config remote.pushdefault github $ git push Signed-off-by: Jeff King p...@peff.net --- The implementation feels weird, like the where do we push to code should be factored out from somewhere else. I think what we're doing here is not _wrong_

Re: [PATCH v3 3/5] refs: teach for_each_ref a flag to avoid recursion

2014-01-08 Thread Jeff King
On Tue, Jan 07, 2014 at 10:47:33PM -0500, Jeff King wrote: On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote: + if (flags DO_FOR_EACH_NO_RECURSE) { + struct ref_dir *subdir = get_ref_dir(entry); + sort_ref_dir

Re: [PATCH 4/5] branch_get: provide per-branch pushremote pointers

2014-01-08 Thread Jeff King
On Wed, Jan 08, 2014 at 04:35:31AM -0500, Jeff King wrote: @@ -385,8 +387,11 @@ static int handle_config(const char *key, const char *value, void *cb) name = key + 7; /* Handle remote.* variables */ - if (!strcmp(name, pushdefault)) - return git_config_string

[PATCH] t5531: further matching fixups

2014-01-08 Thread Jeff King
-01-04) because t5531.6 is trying to provoke a failure of git push due to a submodule check. When combined with b2ed944 the push still fails, but for the wrong reason (because our upstream setup does not exist, not because of the submodule). Signed-off-by: Jeff King p...@peff.net --- On Wed, Jan 08

Re: [PATCH 4/5] branch_get: provide per-branch pushremote pointers

2014-01-08 Thread Jeff King
On Wed, Jan 08, 2014 at 05:27:07AM -0500, Jeff King wrote: This patch passes the test suite by itself (with or without that fixup). But oddly, it seems to fail t5531 when merged with 'next'. I can't figure out why, though. It shouldn't affect any code that doesn't look at branch-pushremote

Re: [PATCH v4 23/28] Support shallow fetch/clone over smart-http

2014-01-08 Thread Jeff King
On Thu, Dec 05, 2013 at 08:02:50PM +0700, Nguyễn Thái Ngọc Duy wrote: 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 | 31

Re: [PATCH 5/5] implement @{publish} shorthand

2014-01-09 Thread Jeff King
On Wed, Jan 08, 2014 at 03:42:09PM -0800, Junio C Hamano wrote: This patch introduces the branch@{publish} shorthand (or @{pu} to be even shorter). It refers to the tracking If @{u} can already be used for upstream, why not allow @{p} but require two letters @{pu}? Just being curious---I

Re: [PATCH v3 3/5] refs: teach for_each_ref a flag to avoid recursion

2014-01-09 Thread Jeff King
On Wed, Jan 08, 2014 at 12:29:51PM +0100, Michael Haggerty wrote: Here's a fixed version of patch 3/5. v2 4/5 doesn't apply cleanly on top of v3 3/5. So I'm basing my review on the branch you have at GitHub peff/git jk/cat-file-warn-ambiguous; I hope it is the same. Hrmph. I didn't have

Re: [PATCH v3 3/5] refs: teach for_each_ref a flag to avoid recursion

2014-01-09 Thread Jeff King
On Thu, Jan 09, 2014 at 09:51:24AM -0800, Junio C Hamano wrote: On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote: + if (flags DO_FOR_EACH_NO_RECURSE) { + struct ref_dir *subdir = get_ref_dir(entry

Re: [PATCH] t5537: fix incorrect expectation in test case 10

2014-01-09 Thread Jeff King
On Wed, Jan 08, 2014 at 07:13:19PM +0700, Nguyễn Thái Ngọc Duy wrote: Commit 48d25ca adds a new commit 7 to the repo that the next test case in commit 1609488 clones from. But the next test case does not expect this commit. For these tests, it's the bottom that's important, not the top. Fix

Re: [PATCH 5/5] implement @{publish} shorthand

2014-01-09 Thread Jeff King
On Thu, Jan 09, 2014 at 08:39:44AM -, Philip Oakley wrote: From: Jeff King p...@peff.net Sent: Wednesday, January 08, 2014 9:37 AM In a triangular workflow, you may have a distinct @{upstream} that you pull changes from, but publish by default (if you typed git push) to a different

Re: [PATCH v3 3/5] refs: teach for_each_ref a flag to avoid recursion

2014-01-10 Thread Jeff King
On Fri, Jan 10, 2014 at 09:59:25AM +0100, Michael Haggerty wrote: However, is it safe to prime only part of the loose ref namespace? [...] prime_ref_dir() is called by do_for_each_entry(), which all the iteration functions pass through. It is always called before the iteration starts,

Re: [PATCH v2 4/5] get_sha1: speed up ambiguous 40-hex test

2014-01-10 Thread Jeff King
On Wed, Jan 08, 2014 at 05:09:25PM +0100, Michael Haggerty wrote: It's not only racy WRT other processes. If the current git process would create a new reference, it wouldn't be reflected in the cache. It's true that the main ref_cache doesn't invalidate itself automatically either when a

Re: [PATCH] t5531: further matching fixups

2014-01-10 Thread Jeff King
On Fri, Jan 10, 2014 at 03:34:59PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: ... but the failing test is actually somewhat broken in 'next' already. Hmph, in what way? I haven't seen t5531 breakage on 'next', with or without your series... The test still passes

Re: [PATCH 3/3] remote: introduce and fill branch-pushremote

2014-01-13 Thread Jeff King
On Sun, Jan 12, 2014 at 10:41:06PM +0530, Ramkumar Ramachandra wrote: When a caller uses branch_get() to retrieve a struct branch, they get the per-branch remote name and a pointer to the remote struct. However, they have no way of knowing about the per-branch pushremote from this interface.

Re: [PATCH 3/3] remote: introduce and fill branch-pushremote

2014-01-13 Thread Jeff King
On Mon, Jan 13, 2014 at 04:52:52PM +0530, Ramkumar Ramachandra wrote: Not sure I understand what the problem is. Let's say we have two branches: master, and side with remote.pushdefault = ram, branch.*.remote = origin, and branch.side.pushremote = peff. Now, when I query master's pushremote,

Re: [PATCH 3/3] remote: introduce and fill branch-pushremote

2014-01-13 Thread Jeff King
On Mon, Jan 13, 2014 at 12:15:08PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: It does not matter for actually pushing, because to do a non-default push, you must always specify a remote. But @{publish} will ask the question even if I am on 'side' now, what would happen

Re: [PATCH v2 4/5] get_sha1: speed up ambiguous 40-hex test

2014-01-14 Thread Jeff King
On Fri, Jan 10, 2014 at 04:41:20AM -0500, Jeff King wrote: That being said, we could further optimize this by not opening the files at all (and make that the responsibility of do_one_ref, which we are avoiding here). I am slightly worried about the open() cost of my solution. It's amortized

Re: BUG: check-ref-format and rev-parse can not handle branches with an @ in their name combined with @{u}

2014-01-14 Thread Jeff King
On Tue, Jan 14, 2014 at 03:45:27PM -0800, Junio C Hamano wrote: Yet 'git check-ref-format --branch @mybranch@{u}' claims @mybranch is an invalid branch name. I do not think it claims any such thing. $ git check-ref-format --branch @foo@{u}; echo $? fatal: '@foo@{u}' is not a

Re: BUG: check-ref-format and rev-parse can not handle branches with an @ in their name combined with @{u}

2014-01-14 Thread Jeff King
On Tue, Jan 14, 2014 at 11:46:58PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: Is that what --branch does? I have never used it, but the manpage seems to suggest it is about _parsing_ (which, IMHO, means it probably should have been an option to rev-parse

[PATCH 0/5] interpret_branch_name bug potpourri

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 12:00:03AM -0500, Jeff King wrote: $ git rev-parse --symbolic-full-name HEAD@{u} refs/remotes/origin/master $ git rev-parse --symbolic-full-name @mybranch@{u} @mybranch@{u} fatal: ambiguous argument '@mybranch@{u}': unknown revision or path

[PATCH 1/5] interpret_branch_name: factor out upstream handling

2014-01-15 Thread Jeff King
simpler to further refactor the function in future patches. While we're at it, let's also break apart the refactored code into a few helper functions. These will be useful if we eventually implement similar @{upstream}-like constructs. Signed-off-by: Jeff King p...@peff.net --- This is identical

[PATCH 2/5] interpret_branch_name: rename cp variable to at

2014-01-15 Thread Jeff King
In the original version of this function, cp acted as a pointer to many different things. Since the refactoring in the last patch, it only marks the at-sign in the string. Let's use a more descriptive variable name. Signed-off-by: Jeff King p...@peff.net --- Obviously can be squashed

[PATCH 3/5] interpret_branch_name: always respect namelen parameter

2014-01-15 Thread Jeff King
the code more obviously correct, and to future-proof us against callers with more exotic buffers. Signed-off-by: Jeff King p...@peff.net --- sha1_name.c| 17 ++--- t/t1508-at-combinations.sh | 15 ++- 2 files changed, 24 insertions(+), 8 deletions

[PATCH 4/5] interpret_branch_name: avoid @{upstream} past colon

2014-01-15 Thread Jeff King
that the upstream mark we found is actually a pathname, and should be disregarded completely. This patch implements that logic. Signed-off-by: Jeff King p...@peff.net --- I think this would actually be cleaner if get_sha1() simply did the colon-parsing first, and omitted the first pass completely. Then sub

[PATCH 5/5] interpret_branch_name: find all possible @-marks

2014-01-15 Thread Jeff King
to find the left-most one in this case (and we then recurse as HEAD@{upstream}). Signed-off-by: Jeff King p...@peff.net --- And this one actually fixes Keith's bug. The diff is noisy due to indentation changes; try it with -b for increased reading pleasure. sha1_name.c | 20

Re: After stash pop, refs/stash become 40 zeroes

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 01:56:52PM +0800, 乙酸鋰 wrote: what are the possible causes of this? After stash pop, refs/stash becomes 40 zeroes. This is the only stash, so refs/stash should be deleted after pop. However, it becomes 40 zeroes. git 1.8.x I can't reproduce the problem here. Running

Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-15 Thread Jeff King
On Tue, Jan 14, 2014 at 02:42:09PM -0500, Martin Langhoff wrote: On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick mf...@codeaurora.org wrote: Perhaps the receiving process is dying hard and leaving stuff behind? Out-of-memory, out of disk space? Yes, that's my guess as well. This server had

Re: hooks scripts and noexec partition

2014-01-15 Thread Jeff King
On Tue, Jan 14, 2014 at 04:41:03PM +0100, krz...@gmail.com wrote: git can't execute hooks no partitions mounted with noexec - even if those are just scripts with shebang line Right. Git does not know that they are shell (or other) scripts; they could be anything, and the advertised interface

Re: git-log --cherry-pick gives different results when using tag or tag^{}

2014-01-15 Thread Jeff King
[+cc Junio, as the bug blames to him] On Fri, Jan 10, 2014 at 02:15:40PM +0100, Francis Moreau wrote: In mykernel repository, I'm having 2 different behaviours with git-log but I don't understand why: Doing: $ git log --oneline --cherry-pick --left-right v3.4.71-1^{}...next and

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-15 Thread Jeff King
with the multiple levels of filtering (which can cause problems when they are out of sync), or even forbid one-level refs entirely. However, those decisions can come later; this fixes the most immediate problem, which is the mismatch between the two. Signed-off-by: Jeff King p...@peff.net

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 05:46:13AM -0500, Jeff King wrote: This discussion stalled, but I finally got around to looking at it today. I agree that we should leave aside more complex policy for now, and start with bringing the fetch and fetch-pack filters into harmony. That turns off format

Re: [PATCH 3/6] read-cache: connect to file watcher

2014-01-15 Thread Jeff King
On Sun, Jan 12, 2014 at 06:03:39PM +0700, Nguyễn Thái Ngọc Duy wrote: This patch establishes a connection between a new file watcher daemon and git. Each index file may have at most one file watcher attached to it. The file watcher maintains a UNIX socket at $GIT_DIR/index.watcher. Any

Re: Consistency question

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote: The question is what guarantees I have with regard to the commit date of a commit in relation to that of its parent commits: a) none b) commitdate(child) = commitdate(parent) c) commitdate(child) commitdate(parent) a) none

[PATCH] do not discard revindex when re-preparing packfiles

2014-01-15 Thread Jeff King
is simple and safe both for current and future code. Signed-off-by: Jeff King p...@peff.net --- On top of jk/pack-bitmap. pack-revindex.c | 11 --- pack-revindex.h | 1 - sha1_file.c | 1 - 3 files changed, 13 deletions(-) diff --git a/pack-revindex.c b/pack-revindex.c index 0bb13b1

Re: git-log --cherry-pick gives different results when using tag or tag^{}

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 11:57:39AM -0800, Junio C Hamano wrote: Where do we pass down other flags from tags to commits? For example, if we do this: $ git log ^v1.8.5 master we mark v1.8.5 tag as UNINTERESTING, and throw that tag (not commit v1.8.5^0) into revs-pending.objects[].

Re: revision: propagate flag bits from tags to pointees

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 12:26:13PM -0800, Junio C Hamano wrote: With the previous fix 895c5ba3 (revision: do not peel tags used in range notation, 2013-09-19), handle_revision_arg() that processes command line arguments for the git log family of commands no longer directly places the object

Re: git quietly fails on https:// URL, https errors are never reported to user

2014-01-16 Thread Jeff King
On Thu, Jan 16, 2014 at 04:27:03AM -0800, Yuri wrote: While debugging, I find that remove_junk() deletes all directories from under __cxa_finalize. Before this, exit(128) is called from recvline_fh (Debug: Remote helper quit.) And this function in turn is called from under refs =

[PATCH 0/5] diff_filespec cleanups and optimizations

2014-01-16 Thread Jeff King
I recently came across a repository with a commit containing 100 million paths in its tree. Cleverly, the whole repo fits into a 1.5K packfile (can you guess how it was done?). Not so cleverly, running diff-tree --root on that commit uses a large amount of memory. :) I do not think it is worth

[PATCH 1/5] diff_filespec: reorder dirty_submodule macro definitions

2014-01-16 Thread Jeff King
{ DIRTY_SUBMODULE_UNTRACKED = 1, DIRTY_SUBMODULE_MODIFIED = 2 } dirty_submodule; would be more obvious, but it bloats the structure. Limiting the enum size like: } dirty_submodule : 2; might work, but it is not portable. Signed-off-by: Jeff King p...@peff.net --- diffcore.h | 2 +- 1

[PATCH 2/5] diff_filespec: drop funcname_pattern_ident field

2014-01-16 Thread Jeff King
This struct field was obsoleted by be58e70 (diff: unify external diff and funcname parsing code, 2008-10-05), but we forgot to remove it. Signed-off-by: Jeff King p...@peff.net --- 8 bytes of our size savings come here... diffcore.h | 1 - 1 file changed, 1 deletion(-) diff --git a/diffcore.h

[PATCH 3/5] diff_filespec: drop xfrm_flags field

2014-01-16 Thread Jeff King
The only mention of this field in the code is by some debugging code which prints it out (and it will always be zero, since we never touch it otherwise). It was obsoleted very early on by 25d5ea4 ([PATCH] Redo rename/copy detection logic., 2005-05-24). Signed-off-by: Jeff King p...@peff.net

[PATCH 4/5] diff_filespec: reorder is_binary field

2014-01-16 Thread Jeff King
-off-by: Jeff King p...@peff.net --- diffcore.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diffcore.h b/diffcore.h index 22993e1..d911bf0 100644 --- a/diffcore.h +++ b/diffcore.h @@ -45,9 +45,9 @@ struct diff_filespec { #define DIRTY_SUBMODULE_MODIFIED 2 unsigned

  1   2   3   4   5   6   7   8   9   10   >