Hi,
On Thu, Mar 19, 2015 at 12:23 AM, Matthieu Moy
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 the
> documentation says
Hi,
On Thu, Mar 19, 2015 at 3:26 AM, Eric Sunshine wrote:
> On Wed, Mar 18, 2015 at 3:04 AM, Paul Tan 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
>> +++ b/t/t0302-credential-store.sh
>> @@
On Fri, Mar 20, 2015 at 9:19 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>> 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
On Fri, Mar 20, 2015 at 8:31 PM, Junio C Hamano wrote:
> Stefan Beller 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
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> 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(stru
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
>
> 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 t
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> 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 @
Stefan Beller 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 inside the
Stefan Beller writes:
> oldlines is allocated earlier in the function and also freed on the
> successful code path.
>
> Signed-off-by: Stefan Beller
> ---
> builtin/apply.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 65b97ee..e152c4d 100644
Stefan Beller writes:
> `old` is not used outside the loop and would get lost
> once we reach the goto.
>
> Signed-off-by: Stefan Beller
> ---
> builtin/update-index.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index 5878986..6271b
Stefan Beller 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 between two scho
Stefan Beller 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 to free `ce` ou
"Kyle J. McKay" 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
polish it fu
Stefan Beller 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 http://vger.kernel.org/majordomo-info.html
On Mar 20, 2015, at 16:29, Stefan Beller wrote:
On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay
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 writes the mail fi
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
---
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 +1462,7 @@ void release_
Signed-off-by: Stefan Beller
---
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, struct blob *obj)
`old` is not used outside the loop and would get lost
once we reach the goto.
Signed-off-by: Stefan Beller
---
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
--- a/builtin/update-index.c
+++
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
---
read-cache.c | 7 +--
1 f
`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 B
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 it
Signed-off-by: Stefan Beller
---
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 int cat_one_file(i
Signed-off-by: Stefan Beller
---
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 cmd_ls_files(int argc
Signed-off-by: Stefan Beller
---
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
+++ b/builtin/merge-base.c
@@ -22,6 +22,7 @
Signed-off-by: Stefan Beller
---
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 commit_index_files(void)
stat
oldlines is allocated earlier in the function and also freed on the
successful code path.
Signed-off-by: Stefan Beller
---
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
+++ b/builtin/apply
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
---
http-push.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/http-push.c b/http-push.c
index bfb1c96..c98dad2 100644
--- a/http-
Signed-off-by: Stefan Beller
---
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(+)
diff --git a/buil
Signed-off-by: Stefan Beller
---
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 soon, so then it g
Signed-off-by: Stefan Beller
---
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, const char
*path,
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
read-c
On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay wrote:
> Has this been merged to 'next'?
Usually Junio writes the mail first and then does a git push
just before being done for the day. At least that's my suspicion as an
observer of
the timing when git fetch returns new shiny stuff and when thes
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: con
On Fri, Mar 20, 2015 at 6:04 AM, Jeff King 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 improved th
Stefan Beller writes:
> ... I'd rather be looking for
>
>man_or_pdf_when_possible git add
>
> and I could alias man_or_pdf_when_possible to a short name.
The help framework can choose the backend and the format and it
wouldn't be too outlandish to do "git help --pdf add" as Philip
mentioned
Stefan Beller writes:
> Thomas referencing reading the man page offline, made me wonder
> why you wouldn't read the man pages itself as they can also be
> carried around offline. But the striking point is "on an iPad", which
> doesn't offer you the convenience of a shell etc, but pdf is fine to r
On Fri, Mar 20, 2015 at 1:21 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> ... though how would I read man pages in pdf
>> format? I tried searching the web and all I can find is how
>> to convert the a man page to pdf. So is there a conveniant
>> way to tell `man` to prefer opening pdfs
From: "Junio C Hamano"
Stefan Beller writes:
... though how would I read man pages in pdf
format? I tried searching the web and all I can find is how
to convert the a man page to pdf. So is there a conveniant
way to tell `man` to prefer opening pdfs when available?
I presume that "man -Tpdf
On 03/20, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Allow adding a TEST_GIT_TEST_SPLIT_INDEX variable to config.mak to run
> > the test suite with split index enabled.
> >
> > Signed-off-by: Thomas Gummerer
>
> > ---
>
> Hmm, it is not wrong per-se, but would it be too much trouble to
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Now we are almost at the end of week #6, and hopefully we can do a
-rc0 late next week to start wrapping this cycle up.
You can find the change
2015-03-20 22:28 GMT+01:00 Junio C Hamano :
> I think you misunderstood me. I am not dismissing the need for PDF;
> I am just saying that there is no need to directly generate them
> from asciidoc sources, especially when there are already manpages
> and html pages available as source to "print" t
Thomas Gummerer writes:
> Allow adding a TEST_GIT_TEST_SPLIT_INDEX variable to config.mak to run
> the test suite with split index enabled.
>
> Signed-off-by: Thomas Gummerer
> ---
Hmm, it is not wrong per-se, but would it be too much trouble to do
GIT_TEST_SPLIT_INDEX=YesPlease make test
The split index extension uses ewah bitmaps to mark index entries as
deleted, instead of removing them from the index directly. This can
result in an on-disk index, in which entries of stage #0 and higher
stages appear, which are removed later when the index bases are merged.
15999d0 read_index_f
> I've now tried to set the GIT_TEST_SPLIT_INDEX environment variable
> and run the tests, and quite a few seem to fail for both v3 and v4.
> I'm looking into that now, but that seems to be unrelated to index v4,
> and I'm not sure yet if I'm testing the right thing.
So now I've tracked it down, 1
Allow adding a TEST_GIT_TEST_SPLIT_INDEX variable to config.mak to run
the test suite with split index enabled.
Signed-off-by: Thomas Gummerer
---
Makefile | 6 ++
t/test-lib.sh | 6 ++
2 files changed, 12 insertions(+)
diff --git a/Makefile b/Makefile
index 44f1dd1..55e558a 100644
Thomas Schneider writes:
>> Personally, I honestly am not quite sure why anybody wants to
>> generate manpages in the PDF format like this patch does, unless
>> they are planning to print them on paper, in which case the existing
>> manpages (git.1 and friends) or html pages (git.html and friends
2015-03-20 21:21 GMT+01:00 Junio C Hamano :
> Stefan Beller writes:
>
>> ... though how would I read man pages in pdf
>> format? I tried searching the web and all I can find is how
>> to convert the a man page to pdf. So is there a conveniant
>> way to tell `man` to prefer opening pdfs when availa
On Fri, Mar 20, 2015 at 04:02:38AM +0530, Sundararajan R wrote:
> Yes. I made a mistake while framing the sentence. I should have proof read
> the commit message more thoroughly. Should I submit a new patch with the
> corrected commit message?
Yeah, you can combine that with the comments from Mat
Stefan Beller writes:
> ... though how would I read man pages in pdf
> format? I tried searching the web and all I can find is how
> to convert the a man page to pdf. So is there a conveniant
> way to tell `man` to prefer opening pdfs when available?
I presume that "man -Tpdf git.1" is not what
On Fri, Mar 20, 2015 at 04:02:39PM -0400, Jeff King wrote:
> Yeah, that was my impression, too. I don't have svn installed on my
> system, so I missed those ones. I don't have CVS either. That might be
> worth following up on.
Hmm, that turned out rather easy. No breakages at all in the cvs tests
On Fri, Mar 20, 2015 at 12:35:56PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Michael J Gruber 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
On 03/20, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > 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
On Fri, Mar 20, 2015 at 12:52:20PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > This is part 1 of n in converting code to use struct object_id.
>
> OK --- 'n' up there looked funny ;-)
It is, unfortunately, a large task. I wish I could quantify it better
than N, but I expect
"brian m. carlson" writes:
> This is part 1 of n in converting code to use struct object_id.
OK --- 'n' up there looked funny ;-)
I'd like to see the series reviewed by those who recently worked
heavily on the subsystem involved (namely, refs API); please do not
forget to include area experts t
Thomas Gummerer writes:
> 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
> ---
>> An updated patch to mention "when r
Junio C Hamano writes:
> Michael J Gruber 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
>> ---
>> t/t2026-prune
From: "Stefan Beller"
On Fri, Mar 20, 2015 at 4:23 AM, Thomas Schneider
wrote:
Signed-off-by: Thomas Schneider
---
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 r
Update callbacks to take the proper parameters and use struct object_id
elsewhere in the callbacks.
Signed-off-by: brian m. carlson
---
builtin/replace.c | 14 +++---
refs.c| 4 ++--
refs.h| 2 +-
replace_object.c | 4 ++--
4 files changed, 12 insertions(+), 1
To allow piecemeal conversion of the for_each_*_ref functions, introduce
an additional typedef for a callback function that takes struct
object_id * instead of unsigned char *. Provide an extra field in
struct ref_entry_cb for this callback and ensure at most one is set at a
time. Temporarily suf
Remove the temporary for_each_ref_in_oid function and update the users
of it. Convert the users of for_each_branch_ref and
for_each_remote_ref (which use for_each_ref_in under the hood) as well.
Signed-off-by: brian m. carlson
---
bisect.c| 8
builtin/rev-parse.c | 10
Convert for_each_ref, for_each_glob_ref, and for_each_glob_ref_in to use
struct object_id, as the latter two call the former with the function
pointer they are provided.
Convert callers to refer to properly-typed functions. Convert uses of
the constant 20 to GIT_SHA1_RAWSZ. Where possible, conve
Convert callbacks to use struct object_id internally as well.
Signed-off-by: brian m. carlson
---
builtin/branch.c | 4 ++--
builtin/describe.c | 12 ++--
builtin/for-each-ref.c | 4 ++--
builtin/fsck.c | 16
refs.c | 10 +-
re
Now that all the callers of handle_refs are gone, rename handle_refs_oid
to handle_refs and update the callers accordingly.
Signed-off-by: brian m. carlson
---
revision.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/revision.c b/revision.c
index c2d
Signed-off-by: brian m. carlson
---
refs.c | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/refs.c b/refs.c
index 9edf18b..689a46d 100644
--- a/refs.c
+++ b/refs.c
@@ -129,7 +129,7 @@ struct ref_value {
* null. If REF_I
Signed-off-by: brian m. carlson
---
refs.c | 22 +++---
refs.h | 2 +-
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 941e466..b54525a 100644
--- a/refs.c
+++ b/refs.c
@@ -2099,16 +2099,16 @@ static struct ref_lock *verify_lock(struct ref_l
Signed-off-by: brian m. carlson
---
builtin/fsck.c | 2 +-
builtin/reflog.c | 4 ++--
refs.c | 10 +-
refs.h | 2 +-
revision.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 05616a0..91eb4f6 1
Convert the callers as well.
Signed-off-by: brian m. carlson
---
refs.c | 4 ++--
refs.h | 2 +-
revision.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 75d8970..758bdd9 100644
--- a/refs.c
+++ b/refs.c
@@ -1964,9 +1964,9 @@ int for_each_re
While these functions were needed during the intermediate steps of
converting for_each_ref and friends to struct object_id, there is no
longer any need to have these wrapper functions. Update each of the
functions that the wrapper functions call and remove the _oid wrapper
functions themselves.
S
This is part 1 of n in converting code to use struct object_id.
refs.c, and the for_each_ref series of functions particularly, is the
source for many instances of object IDs in the codebase. Therefore, it
makes sense to convert this series of functions to provide a basis for
further conversions.
Convert for_each_ref_in_submodule and all of its caller. Introduce two
temporary wrappers in revision.c to handle the incompatibilities between
each_ref_fn and each_ref_fn_oid.
Signed-off-by: brian m. carlson
---
refs.c | 10 +-
refs.h | 8
revision.c | 28 +
Convert head_ref and head_ref_submodule to use struct object_id.
Introduce some wrappers in some of the callers to handle
incompatibilities between each_ref_fn and each_ref_fn_oid.
Signed-off-by: brian m. carlson
---
builtin/show-ref.c | 7 ++-
log-tree.c | 7 ++-
reachable.c
do_for_each_ref was unused due to previous patches, so rename
do_for_each_ref_oid to do_for_each_ref. Similarly, remove the unused fn
member from struct ref_entry in favor of renaming the fn_oid member.
Signed-off-by: brian m. carlson
---
refs.c | 43 +++
each_ref_fn is no longer used, so rename each_ref_fn_oid to each_ref_fn.
Update the documentation to note the change in function signature.
Signed-off-by: brian m. carlson
---
Documentation/technical/api-ref-iteration.txt | 2 +-
refs.c| 48 +-
Convert head_ref_namespaced and for_each_namespaced_ref to use struct
object_id. Update the various callbacks to use struct object_id
internally as well.
Signed-off-by: brian m. carlson
---
http-backend.c | 14 +++---
refs.c | 12 ++--
refs.h | 4 ++--
upload-pa
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
c
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 chang
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 de
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
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
mean
If we are repacking with "-ad", we will drop any unreachable
objects. Likewise, using "-Ad --unpack-unreachable="
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 en
Jeff King 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 http://vger.k
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
---
> An updated patch to mention "when run with TEST_GIT_INDEX_VERSION=4"
> in
Olaf Hering 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 to the a
Thomas Gummerer writes:
> On 03/20, Junio C Hamano wrote:
>> Thomas Gummerer 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 yo
Michael J Gruber 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
> ---
> t/t2026-prune-linked-checkouts.sh | 4 ++--
> t
On Fri, Mar 20, 2015 at 11:00:05AM -0700, Junio C Hamano wrote:
> Junio C Hamano 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 fi
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
>
Junio C Hamano 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 http://github.com/gitster/git
On Fri, Mar 20, 2015 at 10:34:51AM -0700, Junio C Hamano wrote:
> Jeff King 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 possi
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
Michael Haggerty 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 {
> +
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
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 (availab
On 03/20, Junio C Hamano wrote:
> Thomas Gummerer 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
>
Jeff King 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 1 is also
O
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
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
Thomas Gummerer 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 "when run with inde
On Fri, Mar 20, 2015 at 4:23 AM, Thomas Schneider wrote:
> Signed-off-by: Thomas Schneider
> ---
> 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 :)
Welcome
Junio C Hamano writes:
> Jeff King 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/
1 - 100 of 146 matches
Mail list logo
