Re: test -chain lint

Jeff King p...@peff.net writes: [+cc Jonathan, whose patch I apparently subconsciously copied] On Thu, Mar 19, 2015 at 10:08:51PM -0400, Jeff King wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index c096778..02a03d5 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -524,6 +524,21 @@

Re: A git hook that does git cherry-pick and push automatically

On Thu, Mar 19, 2015 at 09:07:28PM -0700, Ray Xie wrote: So today I had a shocking moment while I was doing my cherry-pick, after I performed all the pre-checkin duties (the usual build the code, run the test to make sure the cherry-pick infact works), I found out that my original commit was

Re: [PATCH] git=p4.py rebase now honor's client spec

On 19/03/15 21:58, brian m. carlson wrote: On Thu, Mar 19, 2015 at 12:28:09PM +, Sam Bishop wrote: When using the git-p4.py script, I found that if I used a client spec when cloning out a perforce repository, and then using a git-p4.py rebase, that the rebase command would be using the

Re: test -chain lint (was: [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository)

On Fri, Mar 20, 2015 at 1:10 AM, Jeff King p...@peff.net wrote: On Thu, Mar 19, 2015 at 10:25:32PM -0400, Jeff King wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index c096778..02a03d5 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -524,6 +524,21 @@ test_eval_ () { test_run_

Re: Why is git fetch --prune so much slower than git remote prune?

Michael Haggerty mhag...@alum.mit.edu writes: The lock conflict scenario is the only one that really worries me. Actually, I'd feel worried if this were on the receive-pack side, as it is entirely valid that two or more people make uncoordinated push into a single meeting point, but much less

Re: Fwd: Seems to be pushing more than necessary

That all seems quite reasonable, and is what I would expect to happen. However at the moment, if I create a branch from master and edit one line in one file, with no other changes on the remote, it takes me over an hour to push the new branch. On 19 March 2015 at 18:36, Junio C Hamano

[PATCH 01/25] t/test-lib: introduce --chain-lint option

It's easy to miss an -chain in a test script, like: test_expect_success 'check something important' ' cmd1 cmd2 cmd3 ' The test harness will notice if cmd3 fails, but a failure of cmd1 or cmd2 will go unnoticed, as their exit status is lost after cmd3 runs. The toy

[PATCH 08/25] t: fix -chaining issues around setup which might fail

Many tests have an initial setup step that might fail based on whether earlier tests in the script have succeeded or not. Using a trick like || true breaks the -chain, missing earlier failures (and fooling --chain-lint). We can use test_might_fail in some cases, which is correct and makes the

[PATCH 10/25] t: use test_expect_code instead of hand-rolled comparison

This makes our output in the event of a failure slightly nicer, and it means that we do not break the -chain. Signed-off-by: Jeff King p...@peff.net --- t/t0040-parse-options.sh | 12 +++-- t/t4035-diff-quiet.sh| 66 +++-

[PATCH 09/25] t: use test_might_fail for diff and grep

Some tests run diff or grep to produce an output, and then compare the output to an expected value. We know the exit code we expect these processes to have (e.g., grep yields 0 if it produced output and 1 otherwise), so it would not make the test wrong to look for it. But the difference between

[PATCH 11/25] t: wrap complicated expect_code users in a block

If we are expecting a command to produce a particular exit code, we can use test_expect_code. However, some cases are more complicated, and want to accept one of a range of exit codes. For these, we end up with something like: cmd; case $? in ... That unfortunately breaks the -chain and

[PATCH 12/25] t: avoid using : for comments

The : is not a comment marker, but rather a noop command. Using it as a comment like: : do something cmd1 : something else cmd2 breaks the -chain, and we would fail to notice if cmd1 failed in this instance. We can just use regular # comments instead. Signed-off-by: Jeff King

[PATCH 13/25] t3600: fix -chain breakage for setup commands

As with the earlier patch to fix trivial -chain breakage, these missing operators are not a serious problem (e.g., we do not expect echo to fail). Ironically, however, inserting them shows that some of the commands _do_ fail. Specifically, some of the tests start by making sure we are at a

[PATCH 21/25] t9001: use test_when_finished

The confirmation tests in t9001 all save the value of sendemail.confirm, do something to it, then restore it at the end, in a way that breaks the -chain (they are not wrong, because they save the $? value, but it fools --chain-lint). Instead, they can all use test_when_finished, and we can even

[PATCH 22/25] t0050: appease --chain-lint

Some of the symlink tests check an either-or case using the ||. This is not wrong, but fools --chain-lint into thinking the -chain is broken (in fact, there is no chain here). We can solve this by wrapping the || inside a {} block. This is a bit more verbose, but this construct is rare, and the

[PATCH 15/25] t9502: fix -chain breakage

This script misses a trivial -chain in one of its tests, but it also has a weird reverse: it includes an -chain outside of any test_expect block! This cat should never fail, but if it did, we would not notice, as it would cause us to skip the follow-on test entirely (which does not appear

[PATCH 14/25] t7201: fix -chain breakage

One of these breakages is in setup, but one is more severe and may miss a real test failure. These are pulled out from the rest, though, because we also clean up a few other anachronisms. The most interesting is the use of this here-doc construct: (cat ... EOF ... EOF ) It looks like an

[PATCH 24/25] t0005: fix broken -chains

The : noop command always returns true, so it is fine to include these lines in an -chain (and it appeases --chain-lint). Signed-off-by: Jeff King p...@peff.net --- t/t0005-signals.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh

[PATCH 16/25] t6030: use modern test_* helpers

We can get rid of a lot of hand-rolled error messages by using test_must_fail and test_expect_code. The existing code was careful to use || return 1 when breaking the -chain, but it did fool --chain-lint; the new code is more idiomatic. We also add some uses of test_when_finished, which is less

[PATCH 20/25] t4117: use modern test_* helpers

We can use test_must_fail and test_path_* to avoid some hand-rolled if statements. This makes the code shorter, and makes it more obvious when we are breaking the -chain. Signed-off-by: Jeff King p...@peff.net --- t/t4117-apply-reject.sh | 66 - 1

[PATCH 17/25] t0020: use modern test_* helpers

This test contains a lot of hand-rolled messages to show when the test fails. We can omit most of these by using verbose and test_must_fail. A few of them are for update-index, but we can assume it produces reasonable error messages when it fails. Signed-off-by: Jeff King p...@peff.net ---

[PATCH 19/25] t6034: use modern test_* helpers

These say roughly the same thing as the hand-rolled messages. We do lose the merge did not complete debug message, but merge and write-tree are prefectly capable of writing useful error messages when they fail. Signed-off-by: Jeff King p...@peff.net --- t/t6034-merge-rename-nocruft.sh | 66

[PATCH 25/25] t4104: drop hand-rolled error reporting

This use of || fools --chain-lint into thinking the -chain is broken (and indeed, it is somewhat broken; a failure of update-index in these tests would show the patch file, even if we never got to the part of the test where we fed the patch to git-apply). The extra blocks were there to include

[PATCH 23/25] t7004: fix embedded single-quotes

This test uses single quotes inside the single-quoted test snippet, which effectively makes the contents unquoted. Since they don't need quoted anyway, this isn't a problem, but let's switch them to double-quotes to make it more obviously correct. Signed-off-by: Jeff King p...@peff.net ---

[PATCH 18/25] t1301: use modern test_* helpers

This shortens the code and fixes some -chaining. Signed-off-by: Jeff King p...@peff.net --- t/t1301-shared-repo.sh | 20 +++- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh index 7eecfb8..ac10875 100755 ---

Re: [PATCH 0/25] detecting -chain breakage

On Fri, Mar 20, 2015 at 06:04:30AM -0400, Jeff King wrote: It's a lot of patches, and a few of them are long. I tried to group them by functionality rather than file (though as you can see, some of the tests were unique enough snowflakes that it made sense to discuss their issues separately).

Git ignore help

Hello, I am trying to setup my git ignore (resp. .git/info/exclude) so that I exclude all directories and files except the content of directories that I specifically include (incl. anything within them recursively). I set the .git/info/exclude with the following content: # Exclude

[PATCH] Documentation: Add target to build PDF manpages

Signed-off-by: Thomas Schneider thosc...@gmail.com --- dblatex does print some warnings, but they seem to be irrelevant. Besides, first patch I submit to git or even to any project using a mailing list … let’s hope I did everything right :) Documentation/Makefile | 9 - 1 file changed, 8

Re: [msysGit] Git for Windows 1.9.5.msysgit.1

On Freitag, 20. März 2015 02:15:31 CEST, Mike Hommey wrote: On Fri, Mar 20, 2015 at 12:03:43AM +0100, Thomas Braun wrote: Hi, the Git for Windows team just released the first maintenance release of the Windows-specific installers for git 1.9.5. is it expected that there is no corresponding

So far we have 39 Special Sessions/ Workshops. You can propose your own Special Session

Dear Authors, We would like to invite you to organize a Special Session or a Workshop in CSCC 2015: Circuits, Systems, Communications and Computers www.cscc.co in conjuction with several parallel conferences of INASE.org So far we have 39 Special Sessions/ Workshops. You can propose your own

Re: A git hook that does git cherry-pick and push automatically

David, Thanks for the suggestions, I left out the most unfortunate part of the problem I am facing, the one that add this hook is the git admin, aka our release engineer, so it's a sever side hook that it's forced down to all developers. I sure will try to persuade them from a different

[PATCH 0/25] detecting -chain breakage

This is a cleanup of the -chain lint I posted earlier: http://thread.gmane.org/gmane.comp.version-control.git/265613/focus=265859 I don't know who came up with the idea for it originally, but the concept certainly was floating in the back of my mind from Jonathan's earlier version that is

[PATCH 04/25] t: fix trivial -chain breakage

These are tests which are missing a link in their -chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect).

[PATCH 05/25] t: assume test_cmp produces verbose output

Some tests call test_cmp, and if it fails show the actual output generated. This is mostly pointless, as test_cmp will already show a diff between the expected and actual output. It also fools --chain-lint by putting an || in the middle of the chain, so we'd rather not use this construct. Note

[PATCH 06/25] t: use verbose instead of hand-rolled errors

Many tests that predate the verbose helper function use a pattern like: test ... || { echo ... false } to give more verbose output. Using the helper, we can do this with a single line, and avoid a || which interacts badly with -chaining (besides fooling --chain-lint, we

[PATCH 07/25] t: use test_must_fail instead of hand-rolled blocks

These test scripts likely predate test_must_fail, and can be made simpler by using it (in addition to making them pass --chain-lint). The case in t6036 loses some verbosity in the failure case, but it is so tied to a specific failure mode that it is not worth keeping around (and the outcome of

Re: What's cooking in git.git (Mar 2015, #07; Fri, 20)

On Mar 20, 2015, at 15:02, Junio C Hamano wrote: * bc/object-id (2015-03-13) 10 commits - apply: convert threeway_stage to object_id - patch-id: convert to use struct object_id - commit: convert parts to struct object_id - diff: convert struct combine_diff_path to object_id - bulk-checkin.c:

Re: [PATCH 0/25] detecting -chain breakage

On Fri, Mar 20, 2015 at 6:04 AM, Jeff King p...@peff.net wrote: [...] There were a number of false positives, though as a percentage of the test suite, probably not many (it's just that we have quite a lot of tests). Most of them were in rather old tests, and IMHO the fixes I did actually

[PATCH 08/15] http-push: Remove unneeded cleanup

preq is NULL as the condition the line before dictates. And the cleanup function release_http_pack_request is not null pointer safe. Signed-off-by: Stefan Beller sbel...@google.com --- http-push.c | 1 - 1 file changed, 1 deletion(-) diff --git a/http-push.c b/http-push.c index bfb1c96..c98dad2

[PATCH 05/15] builtin/apply.c: fix a memleak

oldlines is allocated earlier in the function and also freed on the successful code path. Signed-off-by: Stefan Beller sbel...@google.com --- builtin/apply.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/apply.c b/builtin/apply.c index 65b97ee..e152c4d 100644 --- a/builtin/apply.c

[PATCH 02/15] read-cache: Improve readability

Signed-off-by: Stefan Beller sbel...@google.com --- read-cache.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/read-cache.c b/read-cache.c index f72ea9f..769897e 100644 --- a/read-cache.c +++ b/read-cache.c @@ -703,9 +703,7 @@ int add_to_index(struct index_state *istate,

[PATCH 13/15] builtin/unpack-file: fix a memleak

Signed-off-by: Stefan Beller sbel...@google.com --- Notes: This is for discussion again, see 2nd previous patch. However why do we close the fd when we know the program ends soon? So let's also free the memory. builtin/unpack-file.c | 1 + 1 file changed, 1 insertion(+)

[PATCH 12/15] builtin/merge-base: fix memleak

Signed-off-by: Stefan Beller sbel...@google.com --- Notes: see discussion on previous patch. builtin/merge-base.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/merge-base.c b/builtin/merge-base.c index 08a8217..4a8ff02 100644 --- a/builtin/merge-base.c +++

[PATCH 10/15] commit.c: fix a memory leak

Signed-off-by: Stefan Beller sbel...@google.com --- builtin/commit.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index 961e467..da79ac4 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -229,7 +229,7 @@ static int

[PATCH 11/15] builtin/check-attr: fix a memleak

Signed-off-by: Stefan Beller sbel...@google.com --- Notes: I do not quite recall a discussion about such fixes when I started doing these fixes like 2 years ago. As this is a main function of a subcommand the freed memory is likely to have no impact as the process is done

[PATCH 00/15] Fixing memory leaks

So here comes another bunch of mem leak fixes. While I consider the first 10 patches a pretty safe bet, the last 5 hopefully spark a discussion if we want patches which just clean up before the program ends. Stefan Beller (15): read-cache: fix memleak read-cache: Improve readability

[PATCH 14/15] builtin/cat-file: free memleak

Signed-off-by: Stefan Beller sbel...@google.com --- Notes: see discussion builtin/cat-file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/cat-file.c b/builtin/cat-file.c index df99df4..8de6b0d 100644 --- a/builtin/cat-file.c +++ b/builtin/cat-file.c @@ -104,6 +104,7 @@ static

[PATCH 15/15] ls-files: fix a memleak

Signed-off-by: Stefan Beller sbel...@google.com --- Notes: see discussion builtin/ls-files.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/ls-files.c b/builtin/ls-files.c index 914054d..306defa 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c @@ -590,6 +590,7 @@ int

[PATCH 06/15] merge-blobs.c: Fix a memleak

Signed-off-by: Stefan Beller sbel...@google.com --- merge-blobs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/merge-blobs.c b/merge-blobs.c index 57211bc..7abb894 100644 --- a/merge-blobs.c +++ b/merge-blobs.c @@ -14,8 +14,10 @@ static int fill_mmfile_blob(mmfile_t *f,

[PATCH 04/15] update-index: fix a memleak

`old` is not used outside the loop and would get lost once we reach the goto. Signed-off-by: Stefan Beller sbel...@google.com --- builtin/update-index.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/update-index.c b/builtin/update-index.c index 5878986..6271b54 100644 ---

[PATCH 03/15] read-cache: free cache entry in add_to_index in case of early return

This frees `ce` would be leaking in the error path. Additionally a free is moved towards the return. This helps code readability as we often have this pattern of freeing resources just before return/exit and not in between the code. Signed-off-by: Stefan Beller sbel...@google.com ---

[PATCH 01/15] read-cache: fix memleak

`ce` is allocated in make_cache_entry and should be freed if it is not used any more. refresh_cache_entry as a wrapper around refresh_cache_ent will either return `ce` or a new updated cache entry which is allocated to new memory. In that case we need to free `ce` ourselfs. Signed-off-by: Stefan

[PATCH 07/15] merge-recursive: fix memleaks

Usually when using string lists it looks like: struct string_list a = STRING_LIST_INIT_NODUP; // do stuff with a such as string_list_insert(a, test string); print_string_list(a, test prefix); // Cleaning up works on everything inside the struct, not on the // struct itself:

[PATCH 09/15] http: release the memory of a http pack request as well

The cleanup function is used in 4 places now and it's always safe to free up the memory as well. Signed-off-by: Stefan Beller sbel...@google.com --- http.c | 1 + 1 file changed, 1 insertion(+) diff --git a/http.c b/http.c index 9c825af..4b179f6 100644 --- a/http.c +++ b/http.c @@ -1462,6

Re: What's cooking in git.git (Mar 2015, #07; Fri, 20)

On Mar 20, 2015, at 16:29, Stefan Beller wrote: On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay mack...@gmail.com wrote: On Mar 20, 2015, at 15:02, Junio C Hamano wrote: * bc/object-id (2015-03-13) 10 commits [snip] Will cook in 'next'. Has this been merged to 'next'? Usually Junio

Re: What's cooking in git.git (Mar 2015, #07; Fri, 20)

On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay mack...@gmail.com wrote: Has this been merged to 'next'? Usually Junio writes the mail first and then does a git push all the branches just before being done for the day. At least that's my suspicion as an observer of the timing when git fetch

possible minor bug: 'git apply --reject' unnecessarily touches files

Hi I'm doing some splitting of a large patch and I noticed that when I do $ git apply --reject large_patch.diff and it generates a lot of .rej files, it seems to be touching the files that produced the .rej output, even if nothing in that particular file was actually updated. Not a major

[PATCH 26/27] t/*svn*: fix moderate -chain breakage

All of these cases are moderate since they would most probably not lead to missed failing tests: Either they would fail otherwise, or fail a rm in test_when_finished only. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- t/t2026-prune-linked-checkouts.sh | 4 ++--

[PATCH 27/27] t9104: fix test for following larger parents

This test is special for several reasons: It ends with a true statement, which should be a no-op. It is not because the -chain is broken right before it. Also, looking at what the test intended to test according to 7f578c5 (git-svn: --follow-parent now works on sub-directories of larger branches,

Re: [PATCH v4] rev-list: refuse --first-parent combined with --bisect

On Mon, Mar 16, 2015 at 11:53:08AM -0700, Junio C Hamano wrote: Because the history is not linear in Git, bisection works by shrinking a subgraph of the history DAG that contains yet to be tested, suspected to have introduced a badness commits. The subgraph is defined as anything reachable

Re: [PATCH 0/25] detecting -chain breakage

Jeff King venit, vidit, dixit 20.03.2015 11:04: This is a cleanup of the -chain lint I posted earlier: http://thread.gmane.org/gmane.comp.version-control.git/265613/focus=265859 I don't know who came up with the idea for it originally, but the concept certainly was floating in the back

bug in bash completion for git-branch --set-upstream-to on OSX

There appears to be a bug in the bash completion for git-branch when attempting to complete the remote ref argument for --set-upstream-to= When: $ git branch --set-upstream-to=origin/mastTAB I would expect it to complete to: $ git branch --set-upstream-to=origin/master However, the completion

[PATCH] t1700: make test pass with index-v4

The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/t1700-split-index.sh | 15 --- 1 file changed, 12 insertions(+), 3

Re: [PATCH 03/15] read-cache: free cache entry in add_to_index in case of early return

Stefan Beller sbel...@google.com writes: This frees `ce` would be leaking in the error path. At this point ce is not yet added to the index, so it is clear it is safe to free it---otherwise we will leak it. Good. Additionally a free is moved towards the return. I am on the fence on this one

Re: [PATCH 04/15] update-index: fix a memleak

Stefan Beller sbel...@google.com writes: `old` is not used outside the loop and would get lost once we reach the goto. Signed-off-by: Stefan Beller sbel...@google.com --- builtin/update-index.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/update-index.c

Re: [PATCH v4 3/4] docs/git-credential-store: document XDG file and precedence

Hi, On Thu, Mar 19, 2015 at 12:23 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: I would personnally prefer to see this squashed with PATCH 2/4: pushing the bisectable history principle a bit, the state between patches 2 and 3 could be considered broken because the code does not do what

Re: [PATCH 02/15] read-cache: Improve readability

On Fri, Mar 20, 2015 at 9:19 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: Signed-off-by: Stefan Beller sbel...@google.com --- read-cache.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/read-cache.c b/read-cache.c index

Re: [PATCH 03/15] read-cache: free cache entry in add_to_index in case of early return

On Fri, Mar 20, 2015 at 8:31 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: This frees `ce` would be leaking in the error path. At this point ce is not yet added to the index, so it is clear it is safe to free it---otherwise we will leak it. Good.

Re: What's cooking in git.git (Mar 2015, #07; Fri, 20)

Kyle J. McKay mack...@gmail.com writes: Will cook in 'next'. Has this been merged to 'next'? Even fetching github.com/gitster/git.git I'm only seeing it in pu: That was a short-hand for will merge and cook in 'next' ;-) I had an impression that the series may see at least one reroll to

Re: [PATCH 00/15] Fixing memory leaks

Stefan Beller sbel...@google.com writes: So here comes another bunch of mem leak fixes. Looked mostly sensible. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 10/15] commit.c: fix a memory leak

Stefan Beller sbel...@google.com writes: Signed-off-by: Stefan Beller sbel...@google.com --- builtin/commit.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index 961e467..da79ac4 100644 --- a/builtin/commit.c +++

Re: [PATCH 07/15] merge-recursive: fix memleaks

Stefan Beller sbel...@google.com writes: Usually when using string lists it looks like: struct string_list a = STRING_LIST_INIT_NODUP; // do stuff with a such as string_list_insert(a, test string); print_string_list(a, test prefix); // Cleaning up works on everything

Re: [PATCH 02/15] read-cache: Improve readability

Stefan Beller sbel...@google.com writes: Signed-off-by: Stefan Beller sbel...@google.com --- read-cache.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/read-cache.c b/read-cache.c index f72ea9f..769897e 100644 --- a/read-cache.c +++ b/read-cache.c @@ -703,9

Re: [PATCH 01/15] read-cache: fix memleak

Stefan Beller sbel...@google.com writes: `ce` is allocated in make_cache_entry and should be freed if it is not used any more. refresh_cache_entry as a wrapper around refresh_cache_ent will either return `ce` or a new updated cache entry which is allocated to new memory. In that case we need

Re: [PATCH 05/15] builtin/apply.c: fix a memleak

Stefan Beller sbel...@google.com writes: oldlines is allocated earlier in the function and also freed on the successful code path. Signed-off-by: Stefan Beller sbel...@google.com --- builtin/apply.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/apply.c b/builtin/apply.c

Re: [PATCH v4 4/4] t0302: test credential-store support for XDG_CONFIG_HOME

Hi, On Thu, Mar 19, 2015 at 3:26 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Wed, Mar 18, 2015 at 3:04 AM, Paul Tan pyoka...@gmail.com wrote: diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh index f61b40c..5b0a666 100755 --- a/t/t0302-credential-store.sh +++

[PATCH v2 3/5] prune: turn on ref_paranoia flag

Prune should know about broken objects at the tips of refs, so that we can feed them to our traversal rather than ignoring them. It's better for us to abort the operation on the broken object than it is to start deleting objects with an incomplete view of the reachability namespace. Note that for

Re: [PATCH 0/25] detecting -chain breakage

Jeff King p...@peff.net writes: I'm actually about to send out a re-roll of that, as I think all of the review comments have been addressed. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH v2 5/5] refs.c: drop curate_packed_refs

When we delete a ref, we have to rewrite the entire packed-refs file. We take this opportunity to curate the packed-refs file and drop any entries that are crufty or broken. Dropping broken entries (e.g., with bogus names, or ones that point to missing objects) is actively a bad idea, as it means

[PATCH v2 4/5] repack: turn on ref paranoia when doing a destructive repack

If we are repacking with -ad, we will drop any unreachable objects. Likewise, using -Ad --unpack-unreachable=time will drop any old, unreachable objects. In these cases, we want to make sure the reachability we compute with --all is complete. We can do this by passing GIT_REF_PARANOIA=1 in the

[PATCH v2 0/5] not making corruption worse

This is a re-roll of the series to make git prune in a corrupted repository safer. There are only minor tweaks from v1, but I think all of the raised issues were addressed (there was discussion on some other points, but I think they are OK as-is; more discussion is of course welcome). The

[PATCH v2] t1700: make test pass with index-v4

The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- An updated patch to mention when run with

[PATCH v2 1/5] t5312: test object deletion code paths in a corrupted repository

When we are doing a destructive operation like git prune, we want to be extra careful that the set of reachable tips we compute is valid. If there is any corruption or oddity, we are better off aborting the operation and letting the user figure things out rather than plowing ahead and possibly

[PATCH v2 2/5] refs: introduce a ref paranoia flag

Most operations that iterate over refs are happy to ignore broken cruft. However, some operations should be performed with knowledge of these broken refs, because it is better for the operation to choke on a missing object than it is to silently pretend that the ref did not exist (e.g., if we are

Re: [PATCH] Documentation: Add target to build PDF manpages

On Fri, Mar 20, 2015 at 4:23 AM, Thomas Schneider thosc...@gmail.com wrote: Signed-off-by: Thomas Schneider thosc...@gmail.com --- dblatex does print some warnings, but they seem to be irrelevant. Besides, first patch I submit to git or even to any project using a mailing list … let’s hope I

Re: [PATCH] t1700: make test pass with index-v4

Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. I am more interested to see how you managed to use index v4 in the tests be described next to

Re: test -chain lint

On Fri, Mar 20, 2015 at 10:04:43AM -0700, Junio C Hamano wrote: One case where this might misdetect a good test would be this one: test_expect_success 'either succeed or fail with status 1' ' git subcmd || case $? in 1) : happy ;; *) false failure ;; esac ' Yes. Any use of ||

Re: [PATCH] t1700: make test pass with index-v4

On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. I am more interested to see how you managed to use index

Re: [PATCH 15/25] t9502: fix -chain breakage

Am 20.03.2015 um 11:13 schrieb Jeff King: This script misses a trivial -chain in one of its tests, but it also has a weird reverse: it includes an -chain outside of any test_expect block! This cat should never fail, but if it did, we would not notice, as it would cause us to skip the follow-on

Re: [PATCH 01/14] numparse: new module for parsing integral numbers

Michael Haggerty mhag...@alum.mit.edu writes: +static int parse_precheck(const char *s, unsigned int *flags) +{ + const char *number; + + if (isspace(*s)) { + if (!(*flags NUM_LEADING_WHITESPACE)) + return -NUM_LEADING_WHITESPACE; + do

Re: test -chain lint

On Fri, Mar 20, 2015 at 10:34:51AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Your case above is actually better spelled as test_expect_code, but there are more complex one-off cases that I solved using a {} block. Just for the record, test_expect_code expects only one

Re: [PATCH 0/25] detecting -chain breakage

Junio C Hamano gits...@pobox.com writes: I found 2026 and 5312 to be broken (there may be others that are excluded in my usual test set) in 'pu'. As to these topics in git log --first-parent master..pu, my preference is to queue fixups on the broken-out topics (available at

Re: [PATCH 15/25] t9502: fix -chain breakage

On Fri, Mar 20, 2015 at 06:48:35PM +0100, Johannes Sixt wrote: -cat gitweb_config.perl \EOF -$feature{'forks'}{'default'} = [1]; -EOF +test_expect_success 'enable forks feature' ' +cat gitweb_config.perl -\EOF +$feature{'forks'}{'default'} = [1]; +EOF +' This loses the

Re: cover letter and cc list

Olaf Hering o...@aepfle.de writes: What does it take to send the cover letter to all people which are listed in the Cc: list of the following patches? Each patch has a different Cc: list. The git send-email --help command suggests that this cmdline should do it. But the cover letter goes just

Re: [PATCH 0/25] detecting -chain breakage

On Fri, Mar 20, 2015 at 03:28:11PM +0100, Michael J Gruber wrote: With 1/25 only, I get 163 dubious or failed on current next. With 1/25 and only chain-lint without running the actual test loads, I get 213. So, just as Jeff explained, we don't want a chain-lint-only mode because it does

cover letter and cc list

What does it take to send the cover letter to all people which are listed in the Cc: list of the following patches? Each patch has a different Cc: list. The git send-email --help command suggests that this cmdline should do it. But the cover letter goes just to the address listed in --to=: env

Re: test -chain lint

Jeff King p...@peff.net writes: Your case above is actually better spelled as test_expect_code, but there are more complex one-off cases that I solved using a {} block. Just for the record, test_expect_code expects only one possible good exit status and it does not allow us to say 0 is OK and

Re: [PATCH 0/25] detecting -chain breakage

Thanks. They applied cleanly on 'master' and all looked sensible. I found 2026 and 5312 to be broken (there may be others that are excluded in my usual test set) in 'pu'. As to these topics in git log --first-parent master..pu, my preference is to queue fixups on the broken-out topics

Re: [PATCH 0/25] detecting -chain breakage

On Fri, Mar 20, 2015 at 11:00:05AM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I found 2026 and 5312 to be broken (there may be others that are excluded in my usual test set) in 'pu'. As to these topics in git log --first-parent master..pu, my preference is to

Re: [PATCH 26/27] t/*svn*: fix moderate -chain breakage

Michael J Gruber g...@drmicha.warpmail.net writes: All of these cases are moderate since they would most probably not lead to missed failing tests: Either they would fail otherwise, or fail a rm in test_when_finished only. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net ---

  1   2   >