Re: [PATCH] config doc: add missing list separator for checkout.optimizeNewBranch

[Ævar Arnfjörð Bjarmason]

On Tue, Sep 18 2018, Jeff King wrote:

> On Tue, Sep 18, 2018 at 05:34:49AM +, Ævar Arnfjörð Bjarmason wrote:
>
>> The documentation added in fa655d8411 ("checkout: optimize "git
>> checkout -b "", 2018-08-16) didn't add the double-colon
>> needed for the labeled list separator, as a result the added
>> documentation all got squashed into one paragraph. Fix that by adding
>> the list separator.
>
> Obviously the right thing to do, but your patch does not seem to apply
> on that commit. Looks like you built it on a more recent commit that
> also has checkout.defaultRemote (i.e., probably 'next')?

Yeah, it's based on top of next, which I was testing at the time and
didn't expect that conflict.

Greeting

[Danny Chan]

Dear,

I am working in financial firm in Asia. I have a business to transfer the sum 
of $19.000.000.00 of abandon fund in my office.
If you are,interested in the transaction reply on my email for more details.

Best Regards
Danny Chan.

[PATCH] pack-objects: handle island check for "external" delta base

[Jeff King]

On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote:

> * cc/delta-islands (2018-08-16) 7 commits
>   (merged to 'next' on 2018-08-27 at cf3d7bd93f)
>  + pack-objects: move 'layer' into 'struct packing_data'
>  + pack-objects: move tree_depth into 'struct packing_data'
>  + t5320: tests for delta islands
>  + repack: add delta-islands support
>  + pack-objects: add delta-islands support
>  + pack-objects: refactor code into compute_layer_order()
>  + Add delta-islands.{c,h}
> 
>  Lift code from GitHub to restrict delta computation so that an
>  object that exists in one fork is not made into a delta against
>  another object that does not appear in the same forked repository.
> 
>  Will merge to 'master'.

This needed some conflict resolution with my pack-bitmap-reuse-delta
topic, but there's a subtle bug in the result that went to 'master'.
Details and a fix below.

As a side note, I did this same resolution myself at least twice (for my
personal build and for porting the refreshed delta-reuse series to our
GitHub build), and I wrote the exact same resolution you did both times.
So I think it was an easy mistake to make. :)

-Peff

-- >8 --
Subject: pack-objects: handle island check for "external" delta base

Two recent topics, jk/pack-delta-reuse-with-bitmap and
cc/delta-islands, can have a funny interaction. When
checking if we can reuse an on-disk delta, the first topic
allows base_entry to be NULL when we find an object that's
not in the packing list. But the latter topic introduces a
call to in_same_island(), which needs to look at
base_entry->idx.oid. When these two features are used
together, we might try to dereference a NULL base_entry.

In practice, this doesn't really happen. We'd generally only
use delta islands when packing to disk, since the whole
point is to optimize the pack for serving fetches later. And
the new delta-reuse code relies on having used reachability
bitmaps to determine the set of objects, which we would
typically only do when serving an actual fetch.

However, it is technically possible to combine these
features. And even without doing so, building with
"SANITIZE=address,undefined" will cause t5310.46 to
complain.  Even though that test does not have delta islands
enabled, we still take the address of the NULL entry to pass
to in_same_island(). That function then promptly returns
without dereferencing the value when it sees that islands
are not enabled, but it's enough to trigger a sanitizer
error.

The solution is straight-forward: when both features are
used together, we should pass the oid of the found base to
in_same_island().

This is tricky to do inside a single "if" statement. And
after the merge in f3504ea3dd (Merge branch
'cc/delta-islands', 2018-09-17), that "if" condition is
already getting pretty unwieldy. So this patch moves the
logic into a helper function, where we can easily use
multiple return paths. The result is a bit longer, but the
logic should be much easier to follow.

Signed-off-by: Jeff King 
---
 builtin/pack-objects.c | 68 --
 1 file changed, 52 insertions(+), 16 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 5041818ddf..27cb674124 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1470,6 +1470,57 @@ static void cleanup_preferred_base(void)
done_pbase_paths_num = done_pbase_paths_alloc = 0;
 }
 
+/*
+ * Return 1 iff the object specified by "delta" can be sent
+ * literally as a delta against the base in "base_sha1". If
+ * so, then *base_out will point to the entry in our packing
+ * list, or NULL if we must use the external-base list.
+ *
+ * Depth value does not matter - find_deltas() will
+ * never consider reused delta as the base object to
+ * deltify other objects against, in order to avoid
+ * circular deltas.
+ */
+static int can_reuse_delta(const unsigned char *base_sha1,
+  struct object_entry *delta,
+  struct object_entry **base_out)
+{
+   struct object_entry *base;
+
+   if (!base_sha1)
+   return 0;
+
+   /*
+* First see if we're already sending the base (or it's explicitly in
+* our "excluded" list.
+*/
+   base = packlist_find(_pack, base_sha1, NULL);
+   if (base) {
+   if (!in_same_island(>idx.oid, >idx.oid))
+   return 0;
+   *base_out = base;
+   return 1;
+   }
+
+   /*
+* Otherwise, reachability bitmaps may tell us if the receiver has it,
+* even if it was buried too deep in history to make it into the
+* packing list.
+*/
+   if (thin && bitmap_has_sha1_in_uninteresting(bitmap_git, base_sha1)) {
+   if (use_delta_islands) {
+   struct object_id base_oid;
+   hashcpy(base_oid.hash, base_sha1);
+   if (!in_same_island(>idx.oid, _oid))
+  

Re: Subject: [PATCH 0/9] hdr-check

[Elijah Newren]

Hi Ramsay,

On Tue, Sep 18, 2018 at 5:09 PM Ramsay Jones
 wrote;
> This series follows on from a quick "just before bedtime" exercise
> recently[1]. The new 'hdr-check' target essentially automates what
> Elijah did by hand.

Cool, thanks for doing this.  I believe I only tried to directly check
the toplevel header files (any fixes I made to headers in
subdirectories were just due to their indirect inclusion), so it's not
surprising to see that you needed to fix up some headers in
subdirectories.  It is slightly surprising to me that we've already
gained 6 cases of toplevel header files that needed fixes; that
suggests this hdr-check is even more useful than I would have
suspected.

The Make-fu in patch 1 is beyond the make I know, but the other
patches are all pretty simple and look good to me.

Re: [PATCH] Add an EditorConfig file

[Junio C Hamano]

"brian m. carlson"  writes:

> To make automatically configuring one's editor easier, provide an
> EditorConfig file.  This is an INI-style configuration file that can be
> used to specify editor settings and can be understood by a wide variety
> of editors.  Some editors include this support natively; others require
> a plugin.

Good intentions.  One thing that makes me wonder is how well this
plays with "make style" and how easy will it be to keep their
recommendations in sync.  Ideally, if we can generate one from the
other, or both from a unified source, that would be great.

Re: [PATCH v2 6/6] t9109-git-svn-props.sh: split up several pipes

[Matthew DeVore]

On Mon, Sep 17, 2018 at 6:57 PM Eric Sunshine  wrote:
>
> On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore  wrote:
> > t9109-git-svn-props.sh: split up several pipes
>
> Similar to my comment about 5/6, this title talks about the mechanical
> changes made by the patch but not the intent. Perhaps reword it like
> this:
>
> t9109: avoid swallowing Git exit code upstream of a pipe
>
Here is my new commit description:

t9109: don't swallow Git errors upstream of pipe

'git ... | foo' will mask any errors or crashes in git, so split up such
pipes.

One testcase uses several separate pipe sequences in a row which are
awkward to split up. Wrap the split-up pipe in a function so the
awkwardness is not repeated.

Signed-off-by: Matthew DeVore 

> > diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
> > @@ -190,16 +190,21 @@ EOF
> > +# Note we avoid using pipes in order to ensure that git exits with 0.
>
> This new comment doesn't really add value for someone reading the
> patch without knowing the history leading up to the point the comment
> was added. It should probably be dropped. (The actual text of the
> comment is rather confusing anyhow since avoiding pipes has nothing to
> do with ensuring that git exits with 0, thus another reason why this
> comment ought to be dropped.)
Yes, this comment was worded quite poorly. I've removed it since I
agree it doesn't add a lot of value.

>
> >  test_expect_success 'test propget' "
> > -   git svn propget svn:ignore . | cmp - prop.expect &&
> > +   test_propget () {
> > +   git svn propget $1 $2 >observed
>
> The &&-chain is broken here, which means you're losing the exit status
> from the Git command anyhow (despite the point of the patch being to
> avoid losing it).
Fixed.

>
> Also, for consistency, how about calling this "actual" rather than "observed"?
Done.

>
> > +   cmp - $3
>
> This is just wrong. The "-" argument to 'cmp' says to read from
> standard input, but there is nothing being passed to 'cmp' on standard
> input anymore now that you're removed the pipe. I'm guessing that you
> really meant to use "observed" here (and reverse the order of
> arguments to be consistent with the expect-then-actual idiom).
> Finally, since these (apparently) might be binary, you can use
> test_cmp_bin() instead.
Fixed, except for the test_cmp_bin part. My understanding is that git
svn propget is supposed to be printing human-readable strings. My
understanding is based soley on this page:
http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.propget.html

>
> > +   } &&
> > +   test_propget svn:ignore . prop.expect &&
> > cd deeply &&
> > -   git svn propget svn:ignore . | cmp - ../prop.expect &&
> > -   git svn propget svn:entry:committed-rev nested/directory/.keep \
> > - | cmp - ../prop2.expect &&
> > -   git svn propget svn:ignore .. | cmp - ../prop.expect &&
> > -   git svn propget svn:ignore nested/ | cmp - ../prop.expect &&
> > -   git svn propget svn:ignore ./nested | cmp - ../prop.expect &&
> > -   git svn propget svn:ignore .././deeply/nested | cmp - ../prop.expect
> > +   test_propget svn:ignore . ../prop.expect &&
> > +   test_propget svn:entry:committed-rev nested/directory/.keep \
> > +   ../prop2.expect &&
> > +   test_propget svn:ignore .. ../prop.expect &&
> > +   test_propget svn:ignore nested/ ../prop.expect &&
> > +   test_propget svn:ignore ./nested ../prop.expect &&
> > +   test_propget svn:ignore .././deeply/nested ../prop.expect
> > "
>
> After this patch, the test is even more broken than appears at first
> glance since the test body is inside double-quotes. This means that
> the $1, $2, $3 inside the test_propget() function are getting expanded
> _before_ the function itself is ever defined, to whatever bogus values
> $1, $2, $3 hold at that point. I can't see how this could ever have
> worked (except only appearing to work by pure accident).
Fixed, and here is the new test:

test_expect_success 'test propget' "
test_propget () {
git svn propget \$1 \$2 >actual &&
cmp \$3 actual
} &&
test_propget svn:ignore . prop.expect &&
cd deeply &&
test_propget svn:ignore . ../prop.expect &&
test_propget svn:entry:committed-rev nested/directory/.keep \
../prop2.expect &&
test_propget svn:ignore .. ../prop.expect &&
test_propget svn:ignore nested/ ../prop.expect &&
test_propget svn:ignore ./nested ../prop.expect &&
test_propget svn:ignore .././deeply/nested ../prop.expect
"

I confirmed that git's exit code is being checked by putting "!" in
front of git and making sure the test failed. I made sure that
"actual" was actually being compared and the exit code of "cmp" was
checked by adding "echo foo >> actual &&" before cmp, and again making
sure the test failed. This 

Re: [PATCH v2 5/6] tests: split up pipes

[Matthew DeVore]

On Mon, Sep 17, 2018 at 6:30 PM Eric Sunshine  wrote:
>
> On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore  wrote:
> > tests: split up pipes
>
> This title explains the mechanical changes the patch is making but not
> the intent. Perhaps reword it to say something like:
>
> tests: avoid swallowing Git exit code upstream of a pipe
>
> > Some pipes in tests lose the exit code of git processes, which can mask
> > unexpected behavior. Split these pipes up so that git commands are at
> > the end of pipes rather than the beginning or middle.
>
> Can you say something about how you chose which tests to fix in this
> patch? Is this fixing all such cases or only a subset? It looks like
> it's only fixing "ls-files" and "verify-pack" invocations. If that's
> the case, the commit message should explain that.
>
> Also, missing sign-off.
Fixed - here is the new commit message (I changed the wording of your
header to fit within 50 chars):

tests: don't swallow Git errors upstream of pipes

Some pipes in tests lose the exit code of git processes, which can mask
unexpected behavior like crashes. Split these pipes up so that git
commands are only at the end of pipes rather than the beginning or
middle.

The violations fixed in this patch were found in the process of fixing
pipe placement in a prior patch.

Signed-off-by: Matthew DeVore 

>
> > ---
> > diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> > @@ -51,8 +51,10 @@ pull_to_client () {
> > -   git symbolic-ref HEAD refs/heads/$(echo $heads |
> > -   sed -e "s/^\(.\).*$/\1/") &&
> > +   git symbolic-ref HEAD refs/heads/$(
> > +   echo $heads |
> > +   sed -e "s/^\(.\).*$/\1/"
> > +   ) &&
>
> Why is this change included in the patch? There is no Git invocation
> upstream of a pipe here. While the cleanup itself may be desirable, it
> doesn't belong in this patch.
This actually should have been part of the "tests: standardize pipe
placement" patch, but I did "git commit --fixup=SHA" with the wrong
SHA. Fixed.

Re: [PATCH v2 1/6] CodingGuidelines: add shell piping guidelines

[Matthew DeVore]

On Mon, Sep 17, 2018 at 5:16 PM Eric Sunshine  wrote:
>
> On Mon, Sep 17, 2018 at 6:24 PM Matthew DeVore  wrote:
> > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> > @@ -163,6 +163,35 @@ For shell scripts specifically (not exhaustive):
> > + - In a piped sequence which spans multiple lines, put each statement
> > +   on a separate line and put pipes on the end of each line, rather
> > +   than the start. This means you don't need to use \ to join lines,
> > +   since | implies a join already. Also, do not indent subsequent
> > +   lines; if you need a sequence to visually stand apart from the
> > +   surrounding code, use a blank line before and/or after the piped
> > +   sequence.
> > +
> > +   (incorrect)
> > +   [...]
> > +   (correct)
> > +   echo '...' > expected
>
> Existing tests seem to favor the name "expect" over "expected", so
> perhaps use that instead.
>
> $ git grep '>expect\b' -- t | wc -l
> 2674
> $ git grep '>expected\b' -- t | wc -l
> 1406
Thank you for clarifying that out for me, but I'm not longer using
that example, so it's moot.

>
> > +   git ls-files -s file.1 file.2 file.3 file.4 file.5 |
> > +   awk '{print $1}' |
> > +   sort >observed
>
> This is not a great example since it flatly contradicts the very next
> bit of advice added by this patch about not placing a Git command
> upstream in a pipe. Perhaps come up with an example which doesn't
> suffer this shortcoming.
Done.

>
> I've seen the advice earlier in the thread of not indenting the
> sub-commands in a pipe, but I find that the result makes it far more
> difficult to see which commands are part of the pipe sequence than
> with them indented, so I'm not convinced that this advice should be in
> the guidelines. (But that just my opinion.)
I'm not totally sure either way, nor do I have a strong opinion. I
agree it's probably better to not codify this in the documentation
until there's a great reason to.

>
> > + - In a pipe, any non-zero exit codes returned by processes besides
> > +   the last will be ignored. If there is any possibility some
> > +   non-final command in the pipe will raise an error, prefer writing
> > +   the output of that command to a temporary file with '>' rather than
> > +   pipe it.
>
> It's not so much that we care about losing a non-zero exit code (which
> might be perfectly acceptable depending upon the context) but that we
> care about missing a Git command which outright crashes. So, it might
> make sense to make this text more specific by saying that ("exit code
> indicating a crash" and "Git command") rather than being generic in
> saying only "exit code" and "command".
Fixed.

>
> Also, what about expression like $(git foo) by which a crash of a Git
> command can also be lost? Do we want to talk about that, as well?
Yes, it's probably better to add a point about that. Here is the new
documentation after applying your suggestions:

 - If a piped sequence which spans multiple lines, put each statement
   on a separate line and put pipes on the end of each line, rather
   than the start. This means you don't need to use \ to join lines,
   since | implies a join already.

(incorrect)
grep blob verify_pack_result \
| awk -f print_1.awk \
| sort >actual &&
...

(correct)
grep blob verify_pack_result |
awk -f print_1.awk |
sort >actual &&
...

 - In a pipe, any exit codes returned by processes besides the last
   are ignored. This means that if git crashes at the beginning or
   middle of a pipe, it may go undetected. Prefer writing the output
   of that command to a temporary file with '>' rather than pipe it.

 - The $(git ...) construct also discards git's exit code, so if the
   goal is to test that particular command, redirect its output to a
   temporary file rather than wrap it with $( ).

Letter from Andrew A. Schachter

[Mr. Andrew Schachter (ESQ)]

--
Andrew A. Schachter
Attorney  At Law
General Parts Inc
2808 Falbrook Dr. NE
Cedar Rapids, IA 52402
E-mail; andrewazaz...@aol.com



My name is Andrew A. Schachter Attorney “Agricultural Development Bank.
I’m writing on behalf of Mrs. Tracy Mills of West Side Auto Parts 604
Libby Lane Jacksonville, IL 62650 who wants to invest the sum of
$60,000,000.00 USD (SIXTY MILLION US DOLLARS ONLY) into any lucrative
business that you will suggest and can also handle in your country
without any issues. If you feel you can handle/invest this large amount
of funds please let us know by responding to this email immediately.




Should you prefer I re-contact you with more express facts, you can send
me your:




Full Names:
Personal Profile:
Daytime Telephone No:
Your Company Profile



Thank you for your kind understanding;



Regards


Mr. Andrew Schachter (ESQ)

[PATCH] userdiff.h: add missing declaration (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---

Hi Junio,

... and this is the patch I needed for the current 'pu' branch.

ATB,
Ramsay Jones

 userdiff.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/userdiff.h b/userdiff.h
index dad3fc03c1..b072bfe89a 100644
--- a/userdiff.h
+++ b/userdiff.h
@@ -3,6 +3,8 @@
 
 #include "notes-cache.h"
 
+struct index_state;
+
 struct userdiff_funcname {
const char *pattern;
int cflags;
-- 
2.19.0

[PATCH] fetch-object.h: add missing declaration (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---

Hi Junio,

This is the patch I needed for the current 'next' branch to get
a clean 'hdr-check'

ATB,
Ramsay Jones

 fetch-object.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fetch-object.h b/fetch-object.h
index d2f996d4e8..d6444caa5a 100644
--- a/fetch-object.h
+++ b/fetch-object.h
@@ -1,6 +1,8 @@
 #ifndef FETCH_OBJECT_H
 #define FETCH_OBJECT_H
 
+struct object_id;
+
 void fetch_objects(const char *remote_name, const struct object_id *oids,
   int oid_nr);
 
-- 
2.19.0

[PATCH 9/9] commit-reach.h: add missing declarations (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 commit-reach.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/commit-reach.h b/commit-reach.h
index 7d313e2975..f41d8f6ba3 100644
--- a/commit-reach.h
+++ b/commit-reach.h
@@ -1,12 +1,13 @@
 #ifndef __COMMIT_REACH_H__
 #define __COMMIT_REACH_H__
 
+#include "commit.h"
 #include "commit-slab.h"
 
-struct commit;
 struct commit_list;
-struct contains_cache;
 struct ref_filter;
+struct object_id;
+struct object_array;
 
 struct commit_list *get_merge_bases_many(struct commit *one,
 int n,
-- 
2.19.0

[PATCH 8/9] delta-islands.h: add missing forward declarations (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 delta-islands.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/delta-islands.h b/delta-islands.h
index f9725730f4..b635cd07d8 100644
--- a/delta-islands.h
+++ b/delta-islands.h
@@ -1,6 +1,10 @@
 #ifndef DELTA_ISLANDS_H
 #define DELTA_ISLANDS_H
 
+struct object_id;
+struct packing_data;
+struct commit;
+
 int island_delta_cmp(const struct object_id *a, const struct object_id *b);
 int in_same_island(const struct object_id *, const struct object_id *);
 void resolve_tree_islands(int progress, struct packing_data *to_pack);
-- 
2.19.0

[PATCH 7/9] midx.h: add missing forward declarations (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 midx.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/midx.h b/midx.h
index a210f1af2a..622ddac472 100644
--- a/midx.h
+++ b/midx.h
@@ -3,6 +3,9 @@
 
 #include "repository.h"
 
+struct object_id;
+struct pack_entry;
+
 struct multi_pack_index {
struct multi_pack_index *next;
 
-- 
2.19.0

[PATCH 6/9] refs/refs-internal.h: add missing declarations (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 refs/refs-internal.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/refs/refs-internal.h b/refs/refs-internal.h
index 04425d6d1e..44d53672c7 100644
--- a/refs/refs-internal.h
+++ b/refs/refs-internal.h
@@ -1,8 +1,12 @@
 #ifndef REFS_REFS_INTERNAL_H
 #define REFS_REFS_INTERNAL_H
 
+#include "cache.h"
+#include "refs.h"
 #include "iterator.h"
 
+struct ref_transaction;
+
 /*
  * Data structures and functions for the internal use of the refs
  * module. Code outside of the refs module should use only the public
-- 
2.19.0

[PATCH 5/9] refs/packed-backend.h: add missing declaration (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 refs/packed-backend.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/refs/packed-backend.h b/refs/packed-backend.h
index 640245d3b9..a01a0aff9c 100644
--- a/refs/packed-backend.h
+++ b/refs/packed-backend.h
@@ -1,6 +1,8 @@
 #ifndef REFS_PACKED_BACKEND_H
 #define REFS_PACKED_BACKEND_H
 
+struct ref_transaction;
+
 /*
  * Support for storing references in a `packed-refs` file.
  *
-- 
2.19.0

[PATCH 4/9] refs/ref-cache.h: add missing declarations (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 refs/ref-cache.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/refs/ref-cache.h b/refs/ref-cache.h
index eda65e73ed..3bfb89d2b3 100644
--- a/refs/ref-cache.h
+++ b/refs/ref-cache.h
@@ -1,7 +1,10 @@
 #ifndef REFS_REF_CACHE_H
 #define REFS_REF_CACHE_H
 
+#include "cache.h"
+
 struct ref_dir;
+struct ref_store;
 
 /*
  * If this ref_cache is filled lazily, this function is used to load
-- 
2.19.0

[PATCH 3/9] ewah/ewok_rlw.h: add missing include (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 ewah/ewok_rlw.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ewah/ewok_rlw.h b/ewah/ewok_rlw.h
index 7cdfdd0c02..d487966935 100644
--- a/ewah/ewok_rlw.h
+++ b/ewah/ewok_rlw.h
@@ -19,6 +19,8 @@
 #ifndef __EWOK_RLW_H__
 #define __EWOK_RLW_H__
 
+#include "ewok.h"
+
 #define RLW_RUNNING_BITS (sizeof(eword_t) * 4)
 #define RLW_LITERAL_BITS (sizeof(eword_t) * 8 - 1 - RLW_RUNNING_BITS)
 
-- 
2.19.0

[PATCH 2/9] json-writer.h: add missing include (hdr-check)

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---
 json-writer.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/json-writer.h b/json-writer.h
index fc18acc7d9..83906b09c1 100644
--- a/json-writer.h
+++ b/json-writer.h
@@ -42,6 +42,8 @@
  * of the given strings.
  */
 
+#include "strbuf.h"
+
 struct json_writer
 {
/*
-- 
2.19.0

[PATCH 1/9] Makefile: add a hdr-check target

[Ramsay Jones]

Commit ef3ca95475 ("Add missing includes and forward declarations",
2018-08-15) resulted from the author employing a manual method to
create a C file consisting of a pair of pre-processor #include
lines (for 'git-compat-util.h' and a given toplevel header), and
fixing any resulting compiler errors or warnings.

Add a Makefile target to automate this process. This implementation
relies on the '-include' and '-xc' arguments to the 'gcc' and 'clang'
compilers, which allows us to effectively create the required C
compilation unit on-the-fly. This limits the portability of this
solution to those systems which have such a compiler.

The new 'hdr-check' target can be used to check most header files in
the project (for various reasons, the 'compat' and 'xdiff' directories
are not included). Also, note that individual header files can be
checked directly using the '.hco' extension (read: Hdr-Check Object)
like so:

$ make config.hco
HDR config.h
$

Signed-off-by: Ramsay Jones 
---
 Makefile | 12 
 1 file changed, 12 insertions(+)

diff --git a/Makefile b/Makefile
index b567ccca45..835030e22b 100644
--- a/Makefile
+++ b/Makefile
@@ -1793,6 +1793,7 @@ ifndef V
QUIET_MSGFMT   = @echo '   ' MSGFMT $@;
QUIET_GCOV = @echo '   ' GCOV $@;
QUIET_SP   = @echo '   ' SP $<;
+   QUIET_HDR  = @echo '   ' HDR $<;
QUIET_RC   = @echo '   ' RC $@;
QUIET_SUBDIR0  = +@subdir=
QUIET_SUBDIR1  = ;$(NO_SUBDIR) echo '   ' SUBDIR $$subdir; \
@@ -2675,6 +2676,17 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
 .PHONY: sparse $(SP_OBJ)
 sparse: $(SP_OBJ)
 
+GEN_HDRS := command-list.h unicode-width.h
+EXCEPT_HDRS := $(GEN_HDRS) compat% xdiff%
+CHK_HDRS = $(filter-out $(EXCEPT_HDRS),$(patsubst ./%,%,$(LIB_H)))
+HCO = $(patsubst %.h,%.hco,$(CHK_HDRS))
+
+$(HCO): %.hco: %.h FORCE
+   $(QUIET_HDR)$(CC) -include git-compat-util.h -I. -o /dev/null -c -xc $<
+
+.PHONY: hdr-check $(HCO)
+hdr-check: $(HCO)
+
 .PHONY: style
 style:
git clang-format --style file --diff --extensions c,h
-- 
2.19.0

Subject: [PATCH 0/9] hdr-check

[Ramsay Jones]

This series follows on from a quick "just before bedtime" exercise
recently[1]. The new 'hdr-check' target essentially automates what
Elijah did by hand. I tend to run:

  $ make -h hdr-check >hcout 2>&1
  $ vim hcout

... and I only just realised that if somebody wanted to add this to
an travis CI job (it won't be me), then it would be a good idea to
add '-Werror' to the compiler command; otherwise 'make' would not
exit with an error if the compiler only issues warnings.

This series was built on the current 'master' branch (@2d3b1c576c),
although patches #1-6 apply on v2.19.0. (The last three patches used
to be on 'next' until last night!).

If I merge this to 'next', I have to add an additional patch for a
clean 'hdr-check'. Exactly the same comment for the current 'pu'
branch.

[1] 
https://public-inbox.org/git/b8553a50-6b97-2b45-2f7b-cfe257654...@ramsayjones.plus.com/

ATB,
Ramsay Jones

Ramsay Jones (9):
  Makefile: add a hdr-check target
  json-writer.h: add missing include (hdr-check)
  ewah/ewok_rlw.h: add missing include (hdr-check)
  refs/ref-cache.h: add missing declarations (hdr-check)
  refs/packed-backend.h: add missing declaration (hdr-check)
  refs/refs-internal.h: add missing declarations (hdr-check)
  midx.h: add missing forward declarations (hdr-check)
  delta-islands.h: add missing forward declarations (hdr-check)
  commit-reach.h: add missing declarations (hdr-check)

 Makefile  | 12 
 commit-reach.h|  5 +++--
 delta-islands.h   |  4 
 ewah/ewok_rlw.h   |  2 ++
 json-writer.h |  2 ++
 midx.h|  3 +++
 refs/packed-backend.h |  2 ++
 refs/ref-cache.h  |  3 +++
 refs/refs-internal.h  |  4 
 9 files changed, 35 insertions(+), 2 deletions(-)

-- 
2.19.0

[PATCH v3 5/5] preload-index: update GIT_FORCE_PRELOAD_TEST support

[Ben Peart]

Rename GIT_FORCE_PRELOAD_TEST to GIT_TEST_PRELOAD_INDEX for consistency with
the other GIT_TEST_ special setups and properly document its use.

Add logic in t/test-lib.sh to give a warning when the old variable is set to
let people know they need to update their environment to use the new
variable.

Signed-off-by: Ben Peart 
---
 preload-index.c | 2 +-
 t/README| 3 +++
 t/t7519-status-fsmonitor.sh | 4 ++--
 t/test-lib.sh   | 1 +
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/preload-index.c b/preload-index.c
index 0a4e2933bb..a850e197c2 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -85,7 +85,7 @@ static void preload_index(struct index_state *index,
return;
 
threads = index->cache_nr / THREAD_COST;
-   if ((index->cache_nr > 1) && (threads < 2) && 
git_env_bool("GIT_FORCE_PRELOAD_TEST", 0))
+   if ((index->cache_nr > 1) && (threads < 2) && 
git_env_bool("GIT_TEST_PRELOAD_INDEX", 0))
threads = 2;
if (threads < 2)
return;
diff --git a/t/README b/t/README
index 9b13f6d12e..5670c7aad0 100644
--- a/t/README
+++ b/t/README
@@ -327,6 +327,9 @@ GIT_TEST_INDEX_VERSION= exercises the index read/write 
code path
 for the index version specified.  Can be set to any valid version
 (currently 2, 3, or 4).
 
+GIT_TEST_PRELOAD_INDEX= exercises the preload-index code path
+by overriding the minimum number of cache entries required per thread.
+
 Naming Tests
 
 
diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
index d77012ea6d..8308d6d5b1 100755
--- a/t/t7519-status-fsmonitor.sh
+++ b/t/t7519-status-fsmonitor.sh
@@ -245,9 +245,9 @@ do
git config core.preloadIndex $preload_val &&
if test $preload_val = true
then
-   GIT_FORCE_PRELOAD_TEST=$preload_val; export 
GIT_FORCE_PRELOAD_TEST
+   GIT_TEST_PRELOAD_INDEX=$preload_val; export 
GIT_TEST_PRELOAD_INDEX
else
-   unset GIT_FORCE_PRELOAD_TEST
+   sane_unset GIT_TEST_PRELOAD_INDEX
fi
'
 
diff --git a/t/test-lib.sh b/t/test-lib.sh
index e80c84d13c..8ef86e05a3 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -154,6 +154,7 @@ check_var_migration () {
 
 check_var_migration GIT_FSMONITOR_TEST GIT_TEST_FSMONITOR
 check_var_migration TEST_GIT_INDEX_VERSION GIT_TEST_INDEX_VERSION
+check_var_migration GIT_FORCE_PRELOAD_TEST GIT_TEST_PRELOAD_INDEX
 
 # Use specific version of the index file format
 if test -n "${GIT_TEST_INDEX_VERSION:+isset}"
-- 
2.18.0.windows.1

[PATCH v3 3/5] fsmonitor: update GIT_TEST_FSMONITOR support

[Ben Peart]

Rename GIT_FSMONITOR_TEST to GIT_TEST_FSMONITOR for consistency with the
other GIT_TEST_ special setups and properly document its use.

Add logic in t/test-lib.sh to give a warning when the old variable is set to
let people know they need to update their environment to use the new
variable.

Signed-off-by: Ben Peart 
---
 config.c|  2 +-
 t/README|  4 
 t/t1700-split-index.sh  |  2 +-
 t/t7519-status-fsmonitor.sh |  2 +-
 t/test-lib.sh   | 20 
 5 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/config.c b/config.c
index 3461993f0a..3555c63f28 100644
--- a/config.c
+++ b/config.c
@@ -2278,7 +2278,7 @@ int git_config_get_max_percent_split_change(void)
 int git_config_get_fsmonitor(void)
 {
if (git_config_get_pathname("core.fsmonitor", _fsmonitor))
-   core_fsmonitor = getenv("GIT_FSMONITOR_TEST");
+   core_fsmonitor = getenv("GIT_TEST_FSMONITOR");
 
if (core_fsmonitor && !*core_fsmonitor)
core_fsmonitor = NULL;
diff --git a/t/README b/t/README
index 56a417439c..47165f7eab 100644
--- a/t/README
+++ b/t/README
@@ -319,6 +319,10 @@ GIT_TEST_OE_DELTA_SIZE= exercises the uncommon 
pack-objects code
 path where deltas larger than this limit require extra memory
 allocation for bookkeeping.
 
+GIT_TEST_FSMONITOR=$PWD/t7519/fsmonitor-all exercises the fsmonitor
+code path for utilizing a file system monitor to speed up detecting
+new or changed files.
+
 Naming Tests
 
 
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index b3b4d83eaf..f6a856f24c 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -6,7 +6,7 @@ test_description='split index mode tests'
 
 # We need total control of index splitting here
 sane_unset GIT_TEST_SPLIT_INDEX
-sane_unset GIT_FSMONITOR_TEST
+sane_unset GIT_TEST_FSMONITOR
 
 test_expect_success 'enable split index' '
git config splitIndex.maxPercentChange 100 &&
diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
index 756beb0d8e..d77012ea6d 100755
--- a/t/t7519-status-fsmonitor.sh
+++ b/t/t7519-status-fsmonitor.sh
@@ -8,7 +8,7 @@ test_description='git status with file system watcher'
 # To run the entire git test suite using fsmonitor:
 #
 # copy t/t7519/fsmonitor-all to a location in your path and then set
-# GIT_FSMONITOR_TEST=fsmonitor-all and run your tests.
+# GIT_TEST_FSMONITOR=fsmonitor-all and run your tests.
 #
 
 # Note, after "git reset --hard HEAD" no extensions exist other than 'TREE'
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 44288cbb59..653688c067 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -140,6 +140,26 @@ then
export GIT_INDEX_VERSION
 fi
 
+check_var_migration () {
+   old_name=$1 new_name=$2
+   eval "old_isset=\${${old_name}:+isset}"
+   eval "new_isset=\${${new_name}:+isset}"
+   case "$old_isset,$new_isset" in
+   isset,)
+   echo >&2 "warning: $old_name is now $new_name"
+   echo >&2 "hint: set $new_name too during the transition period"
+   eval "$new_name=\$$old_name"
+   ;;
+   isset,isset)
+   # do this later
+   # echo >&2 "warning: $old_name is now $new_name"
+   # echo >&2 "hint: remove $old_name"
+   ;;
+   esac
+}
+
+check_var_migration GIT_FSMONITOR_TEST GIT_TEST_FSMONITOR
+
 # Add libc MALLOC and MALLOC_PERTURB test
 # only if we are not executing the test with valgrind
 if expr " $GIT_TEST_OPTS " : ".* --valgrind " >/dev/null ||
-- 
2.18.0.windows.1

[PATCH v3 4/5] read-cache: update TEST_GIT_INDEX_VERSION support

[Ben Peart]

Rename TEST_GIT_INDEX_VERSION to GIT_TEST_INDEX_VERSION for consistency with
the other GIT_TEST_ special setups and properly document its use.

Add logic in t/test-lib.sh to give a warning when the old variable is set to
let people know they need to update their environment to use the new
variable.

Signed-off-by: Ben Peart 
---
 Makefile  |  6 +++---
 t/README  |  4 
 t/test-lib.sh | 14 --
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index 5a969f5830..9e84ef02f7 100644
--- a/Makefile
+++ b/Makefile
@@ -400,7 +400,7 @@ all::
 # (defaults to "man") if you want to have a different default when
 # "git help" is called without a parameter specifying the format.
 #
-# Define TEST_GIT_INDEX_VERSION to 2, 3 or 4 to run the test suite
+# Define GIT_TEST_INDEX_VERSION to 2, 3 or 4 to run the test suite
 # with a different indexfile format version.  If it isn't set the index
 # file format used is index-v[23].
 #
@@ -2599,8 +2599,8 @@ endif
 ifdef GIT_INTEROP_MAKE_OPTS
@echo GIT_INTEROP_MAKE_OPTS=\''$(subst ','\'',$(subst 
','\'',$(GIT_INTEROP_MAKE_OPTS)))'\' >>$@+
 endif
-ifdef TEST_GIT_INDEX_VERSION
-   @echo TEST_GIT_INDEX_VERSION=\''$(subst ','\'',$(subst 
','\'',$(TEST_GIT_INDEX_VERSION)))'\' >>$@+
+ifdef GIT_TEST_INDEX_VERSION
+   @echo GIT_TEST_INDEX_VERSION=\''$(subst ','\'',$(subst 
','\'',$(GIT_TEST_INDEX_VERSION)))'\' >>$@+
 endif
@if cmp $@+ $@ >/dev/null 2>&1; then $(RM) $@+; else mv $@+ $@; fi
 
diff --git a/t/README b/t/README
index 47165f7eab..9b13f6d12e 100644
--- a/t/README
+++ b/t/README
@@ -323,6 +323,10 @@ GIT_TEST_FSMONITOR=$PWD/t7519/fsmonitor-all exercises the 
fsmonitor
 code path for utilizing a file system monitor to speed up detecting
 new or changed files.
 
+GIT_TEST_INDEX_VERSION= exercises the index read/write code path
+for the index version specified.  Can be set to any valid version
+(currently 2, 3, or 4).
+
 Naming Tests
 
 
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 653688c067..e80c84d13c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -134,12 +134,6 @@ export EDITOR
 GIT_TRACE_BARE=1
 export GIT_TRACE_BARE
 
-if test -n "${TEST_GIT_INDEX_VERSION:+isset}"
-then
-   GIT_INDEX_VERSION="$TEST_GIT_INDEX_VERSION"
-   export GIT_INDEX_VERSION
-fi
-
 check_var_migration () {
old_name=$1 new_name=$2
eval "old_isset=\${${old_name}:+isset}"
@@ -159,6 +153,14 @@ check_var_migration () {
 }
 
 check_var_migration GIT_FSMONITOR_TEST GIT_TEST_FSMONITOR
+check_var_migration TEST_GIT_INDEX_VERSION GIT_TEST_INDEX_VERSION
+
+# Use specific version of the index file format
+if test -n "${GIT_TEST_INDEX_VERSION:+isset}"
+then
+   GIT_INDEX_VERSION="$GIT_TEST_INDEX_VERSION"
+   export GIT_INDEX_VERSION
+fi
 
 # Add libc MALLOC and MALLOC_PERTURB test
 # only if we are not executing the test with valgrind
-- 
2.18.0.windows.1

[PATCH v3 2/5] preload-index: use git_env_bool() not getenv() for customization

[Ben Peart]

GIT_FORCE_PRELOAD_TEST is only checked for presence by using getenv().
Use git_env_bool() instead so that GIT_FORCE_PRELOAD_TEST=false can
work as expected.

Signed-off-by: Ben Peart 
---
 preload-index.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/preload-index.c b/preload-index.c
index 71cd2437a3..0a4e2933bb 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -5,6 +5,7 @@
 #include "pathspec.h"
 #include "dir.h"
 #include "fsmonitor.h"
+#include "config.h"
 
 #ifdef NO_PTHREADS
 static void preload_index(struct index_state *index,
@@ -84,7 +85,7 @@ static void preload_index(struct index_state *index,
return;
 
threads = index->cache_nr / THREAD_COST;
-   if ((index->cache_nr > 1) && (threads < 2) && 
getenv("GIT_FORCE_PRELOAD_TEST"))
+   if ((index->cache_nr > 1) && (threads < 2) && 
git_env_bool("GIT_FORCE_PRELOAD_TEST", 0))
threads = 2;
if (threads < 2)
return;
-- 
2.18.0.windows.1

[PATCH v3 0/5] Cleanup pass on special test setups

[Ben Peart]

This round has one code change based on feedback. Other changes are just
rewording commit messages.

Base Ref: v2.19.0
Web-Diff: https://github.com/benpeart/git/commit/043246d936
Checkout: git fetch https://github.com/benpeart/git git-test-cleanup-v3 && git 
checkout 043246d936


### Interdiff (v2..v3):

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 17a56f44ad..8ef86e05a3 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -134,12 +134,6 @@ export EDITOR
 GIT_TRACE_BARE=1
 export GIT_TRACE_BARE
 
-if test -n "${GIT_TEST_INDEX_VERSION:+isset}"
-then
-   GIT_INDEX_VERSION="$GIT_TEST_INDEX_VERSION"
-   export GIT_INDEX_VERSION
-fi
-
 check_var_migration () {
old_name=$1 new_name=$2
eval "old_isset=\${${old_name}:+isset}"
@@ -162,6 +156,13 @@ check_var_migration GIT_FSMONITOR_TEST GIT_TEST_FSMONITOR
 check_var_migration TEST_GIT_INDEX_VERSION GIT_TEST_INDEX_VERSION
 check_var_migration GIT_FORCE_PRELOAD_TEST GIT_TEST_PRELOAD_INDEX
 
+# Use specific version of the index file format
+if test -n "${GIT_TEST_INDEX_VERSION:+isset}"
+then
+   GIT_INDEX_VERSION="$GIT_TEST_INDEX_VERSION"
+   export GIT_INDEX_VERSION
+fi
+
 # Add libc MALLOC and MALLOC_PERTURB test
 # only if we are not executing the test with valgrind
 if expr " $GIT_TEST_OPTS " : ".* --valgrind " >/dev/null ||


### Patches

Ben Peart (5):
  t/README: correct spelling of "uncommon"
  preload-index: use git_env_bool() not getenv() for customization
  fsmonitor: update GIT_TEST_FSMONITOR support
  read-cache: update TEST_GIT_INDEX_VERSION support
  preload-index: update GIT_FORCE_PRELOAD_TEST support

 Makefile|  6 +++---
 config.c|  2 +-
 preload-index.c |  3 ++-
 t/README| 13 -
 t/t1700-split-index.sh  |  2 +-
 t/t7519-status-fsmonitor.sh |  6 +++---
 t/test-lib.sh   | 27 +--
 7 files changed, 47 insertions(+), 12 deletions(-)


base-commit: 1d4361b0f344188ab5eec6dcea01f61a3a3a1670
-- 
2.18.0.windows.1

[PATCH v3 1/5] t/README: correct spelling of "uncommon"

[Ben Peart]

Correct a spelling error in the documentation for GIT_TEST_OE_DELTA_SIZE.

Signed-off-by: Ben Peart 
---
 t/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/README b/t/README
index 9028b47d92..56a417439c 100644
--- a/t/README
+++ b/t/README
@@ -315,7 +315,7 @@ packs on demand. This normally only happens when the object 
size is
 over 2GB. This variable forces the code path on any object larger than
  bytes.
 
-GIT_TEST_OE_DELTA_SIZE= exercises the uncomon pack-objects code
+GIT_TEST_OE_DELTA_SIZE= exercises the uncommon pack-objects code
 path where deltas larger than this limit require extra memory
 allocation for bookkeeping.
 
-- 
2.18.0.windows.1

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

[Jeff King]

On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote:

> > I like that, too. It's a little more costly just because it may involve
> > object-db writes, but I think in most cases it would be fine. I almost
> > always "git stash" away discarded changes these days instead of "git
> > reset --hard", because it effectively provides this kind of log.
> 
> Obviously we do eventually turn the index into a tree, which is used
> by the commit. Would it be possible to simply somehow store these
> trees, and have commands which blow the tree away simply instead, save
> it? I'm not sure how costly that is.

For an up-to-date index with the cache-tree extension, this should be
pretty cheap.  Even for a partially-staged index, where we already have
the blob in the object database, it should just incur the tree
computation (and parts you didn't touch would hopefully have an
up-to-date cache-tree).

Where it gets expensive is when you are throwing away working-tree
changes, and you have to re-hash those objects. Conceptually that's not
much worse than just calling `git add`, but there are corner cases
(e.g., imagine you keep a 1GB clone of another project in an ignored
directory, and then `git clean -dx` wants to `git add` all of it).

-Peff

Greetings

[Public Figure]

  TO WHOM IT MAY CONCERN

Greetings,

 

Opportunity for you, I am well recognized and Public Figure occupying a top 
Government position in Federal Republic of Nigerian. I am hereby requiring An 
International expatriates with professional experience in all kind, 
Contractors, Investors and Partnership in any infrastructures projects.

 

For further inquiries contact: centuryinvestments...@gmail.com   

Thanks

Bonjour, J'attends toujours votre réponse s'il vous plaît

[Mme Cécile PULON]

"bonjour mon bien aimé en christ"

Mon nom est Cécile PULON née en Juin 1941, je suis actuellement à l’hôpital 
(Edmonton Alberta de canada) à cause de mon état de santé dégradé, je vous
contact pour un projet de Donation que je compte faire à une personne de bonne 
Moralité qui pourra savoir bien gérer les fonds  ( 9.850.000€ ), 
intervenir dans le social et dans l'humanitaire, créer des Temples de Dieu , 
des Écoles et aider les enfants démunis . Je serai 
heureuse d'avoir une réponse de votre part, j’ai trop réfléchis avant de 
prendre cette décision, j'ai beaucoup prié Dieu afin 
qu'il m'oriente vers son enfant pouvant accomplis cette mission. 

Merci de me répondre sur mon adresse privé : puloncecil...@gmail.com 
Que Dieu tout puissant vous bénisse

Bonjour, J'attends toujours votre réponse s'il vous plaît

[Mme Cécile PULON]

"bonjour mon bien aimé en christ"

Mon nom est Cécile PULON née en Juin 1941, je suis actuellement à l’hôpital 
(Edmonton Alberta de canada) à cause de mon état de santé dégradé, je vous
contact pour un projet de Donation que je compte faire à une personne de bonne 
Moralité qui pourra savoir bien gérer les fonds  ( 9.850.000€ ), 
intervenir dans le social et dans l'humanitaire, créer des Temples de Dieu , 
des Écoles et aider les enfants démunis . Je serai 
heureuse d'avoir une réponse de votre part, j’ai trop réfléchis avant de 
prendre cette décision, j'ai beaucoup prié Dieu afin 
qu'il m'oriente vers son enfant pouvant accomplis cette mission. 

Merci de me répondre sur mon adresse privé : puloncecil...@gmail.com 
Que Dieu tout puissant vous bénisse

Bonjour, J'attends toujours votre réponse s'il vous plaît

[Mme Cécile PULON]

"bonjour mon bien aimé en christ"

Mon nom est Cécile PULON née en Juin 1941, je suis actuellement à l’hôpital 
(Edmonton Alberta de canada) à cause de mon état de santé dégradé, je vous
contact pour un projet de Donation que je compte faire à une personne de bonne 
Moralité qui pourra savoir bien gérer les fonds  ( 9.850.000€ ), 
intervenir dans le social et dans l'humanitaire, créer des Temples de Dieu , 
des Écoles et aider les enfants démunis . Je serai 
heureuse d'avoir une réponse de votre part, j’ai trop réfléchis avant de 
prendre cette décision, j'ai beaucoup prié Dieu afin 
qu'il m'oriente vers son enfant pouvant accomplis cette mission. 

Merci de me répondre sur mon adresse privé : puloncecil...@gmail.com 
Que Dieu tout puissant vous bénisse

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

[Eckhard Maaß]

On Tue, Sep 18, 2018 at 12:41:30PM -0700, Jacob Keller wrote:
> I think having both is good. There are a lot of ways to accidentally
> throw away work, and it's pretty frustrating to have it happen. But
> the reflog is also somewhat complicated, and I've definitely seen a
> lot of developers who've never heard of it, and struggle with the
> concept.

It's definitely good to improve on "oh, I screwed up - how can I
recover?" part. 

> I personally think having the nice "it looks like you're about to
> throw away all your changes, are you sure" style of protection using
> something like --clobber-index is useful as a mode, even if we have an
> index log of sorts.

I don't think it's an appealing design. If we have the index reflog
giving us an undo function, then it is (at least for me) irritating to
have additional protection. Furthermore, this protection, to not break
existing workflows, needs to be configurable. This comes with much
baggage on its own. Having then two things which seem to solve the same
problem setting, but somehow different, is in my opinion even more
confusing in the long run.

Greetings,
Eckhard

Re: Cannot negate `*` ignore pattern for directory with space in the name

[Victor Engmark]

On 19/09/2018 05:59, Duy Nguyen wrote:
> On Tue, Sep 18, 2018 at 6:13 AM Victor Engmark
>  wrote:
[…]
>> $ cat > .gitignore << EOF
>>> *
>>> !foo bar
>>> !foo\ bar
>>> !"foo bar"
> 
> No need to quote, either with double quotes or backslashes. They are
> interpreted as literal " and \

Thanks! I just tried a bunch of things to see if anything stuck.

>> $ git status --short
>> [no output]
> 
> It's not exactly a bug, more like a trap. '*' matches anything, at
> every level. So even if you negate 'foo bar', when we check 'foo
> bar/test', '*' pattern applies again and ignores 'foo bar/test'. If
> the first line in .gitignore is /* instead of * (to keep match
> anything at the top level directory only), then it should work.

You're right, I've managed to induce the placebo effect in myself :)
Thank you for the help, and sorry for the noise!

-- 
Cheers
Victor

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

[Jacob Keller]

On Mon, Sep 17, 2018 at 12:26 PM Junio C Hamano  wrote:
> FWIW, I didn't mean to say that we should give users a way to
> recover.  Your "commit -a" or "commit $path" protection just
> prevents the situation from happening, and I think it is sufficient.
>
> The sole point I wanted to raise by bringing up the above was that
> we should have the same degree of protection against "add $path" or
> "add -u".
>
> Of course, "index log" is interesting and it may even turn out to be
> useful (I was skeptical about "reference log" the same way, but it
> turned out to be useful without burdening the system too heavily),
> and it may even remove the need for the "do not accidentally lose
> information by adding more to the index" protection.  But until that
> happens, if we are to have such a protection, we would wnat to give
> the same degree of protection to "commit" and "add".

I think having both is good. There are a lot of ways to accidentally
throw away work, and it's pretty frustrating to have it happen. But
the reflog is also somewhat complicated, and I've definitely seen a
lot of developers who've never heard of it, and struggle with the
concept.

I personally think having the nice "it looks like you're about to
throw away all your changes, are you sure" style of protection using
something like --clobber-index is useful as a mode, even if we have an
index log of sorts. Having it be default helps new people, even if it
does get in the way of someone who knows what they're doing. Having it
be configurable, to me, sort of defeats the point, since it means
having to tell people to turn this on.

I personally don't mind having to type an extended option to clobber
when I know it's what I want, but I can see that being painful.

However, if we had a reflog for the index, this becomes less of a
problem since recovery is much easier.

Thanks,
Jake

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

[Jacob Keller]

On Mon, Sep 17, 2018 at 11:15 AM Jeff King  wrote:
>
> On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
>
> > > On the other hand, if I am keeping some change that should never be
> > > in a commit in the working tree file, and building the contents in
> > > the index using "add -p" to incrementally, it would be the same
> > > disaster as you are trying to prevent if I by mistake did a whole
> > > path 'add', even if I catch myself doing so before running 'commit'
> > > i.e.
> > >
> > > edit X
> > > git add -p X
> > > git diff --cached X
> > > git diff X
> > > ... repeat the above number of times ...
> > > git add X ;# OOPS!
> > > git add . ;# OOPS! even worse!
> > >
> > > Even though this does not involve "git commit -a" or "git commit X",
> > > an unrecoverable damage that requires redoing the manual work is
> > > already done.
> >
> > I don't see a good way to get to recover this situation. I could go
> > back to the "index log" idea, where we keep a log of index changes (or
> > just "interesting" changes). That way there's no behavior change at
> > all. The user who accidentally updates/deletes something can always
> > retrieve the old content back (assuming that they realize quickly
> > since we can't keep very long log).
>
> FWIW, I like that approach much better, since:
>
>   1. It does not bother or restrict anybody in their workflow; instead,
>  they pay the complexity price only when they know they have made a
>  mistake.
>
>   2. It covers many more cases (e.g., just doing the wrong thing via
>  "add -p").
>

I also think this is a better approach for the same reasons.

> A naive index log would be pretty cheap in CPU, at least for POSIX-ish
> systems. You could just hard link "index" to "index.N" before renaming
> "index.lock" over "index". But I guess if you have a gigantic index,
> that's less appealing. So maybe storing the equivalent of a "--raw" diff
> between the two index states would make more sense (and after all, you
> don't really need the stat-cache or cache-tree). It would cost more to
> reconstruct the index on the fly, but then the point is that you would
> create these logs a lot more than you access them.
>
> > I've been thinking about allowing to undo worktree changes too (e.g.
> > accidental "git reset --hard") and this log can cover it as well.
>
> I like that, too. It's a little more costly just because it may involve
> object-db writes, but I think in most cases it would be fine. I almost
> always "git stash" away discarded changes these days instead of "git
> reset --hard", because it effectively provides this kind of log.
>

Obviously we do eventually turn the index into a tree, which is used
by the commit. Would it be possible to simply somehow store these
trees, and have commands which blow the tree away simply instead, save
it? I'm not sure how costly that is.

Thanks,
Jake

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

[Jacob Keller]

On Mon, Sep 17, 2018 at 10:09 AM Junio C Hamano  wrote:
>
> It usually is safer (simply because you do not have to think about
> it) to start a behaviour change like this as a strict opt-in to gain
> confidence.

I tend to agree, however.. in this case it could be considered safer
to err on the side of not throwing away the index which could have
crafted changes in it.

> The approach to check if the contents in the index matches that in
> the HEAD per-path (i.e. "The contents we are adding to the index is
> whole working tree contents for that path.  But the index already
> has contents different from HEAD for the path---are we losing
> information by doing this?"), is a very good one.  But for the
> protection to be effective, I think "git commit" and "git add"
> should be covered the same way, ideally with the same code and
> possibly the same configuration knob and/or command line option to
> control the behaviour.

Checking both commit and add makes sense to me.

>
> If the information loss caused by the "add/commit X" or "add
> -u/commit -a" is so serious that this new feature deserves to become
> the default (which I do not yet think it is the case, by the way),
> then we could even forbid "commit X" or "commit -a" when the paths
> involved has difference between the index and the HEAD, without any
> configuration knob or command line override for "commit", and then
> tell the users to use "git add/rm" _with_ the override before coming
> back to "git commit".

I was going to suggest we have some sort of reflog equivalent for the
index, but Duy seems to discuss that in a follow-on mail.

>
> How should this new check intract with paths added with "add -N", by
> the way?

Re: Git trademark status and policy

[Jeff King]

On Mon, Sep 17, 2018 at 06:58:43AM -0700, Junio C Hamano wrote:

> I can undertand the sentiment that we may not want to appear drawing
> lines among friends, but ultimately the policy is about protecting
> our friends from non-friends, so whether we like it or not, we may
> have to be more explicit about who's grandfathered and who's not
> than before.

Yeah, I think it may simply come down to that. I think we may need to
get some guidance from Conservancy on the best route forward. I.e., if
we want to bless "Git Cola" as a name, are we best to have some kind of
written agreement, so it is "we explicitly allow this", and is not
interpreted as "we did not bother to enforce, which weakens our
trademark".

-Peff

Re: Git trademark status and policy

[Jeff King]

On Mon, Sep 17, 2018 at 11:25:31AM +0200, Christian Couder wrote:

> > (Also, to be clear, this is all _only_ about "Git Cola". The "git-cola"
> > command is explicitly OK in the policy because that's how commands
> > work).
> 
> I agree about "git-cola" though I wonder about "git-dag" as this is
> another command used by the project that is more generic. For example
> I could imagine that, if we wanted to provide a shortcut for `git log
> --graph --decorate --oneline`, we might want to use `git dag`.
> 
> I guess we can still recommend to change it if possible, though we can
> also acknowledge that, as our recommendation comes very late (too
> late?), it is just a "weak" recommendation.

Yeah, I agree with you, though I think it is a separate issue. "git-dag"
is explicitly OK in the trademark policy, and they are not using "Git
Dag" in any recognizable way.

So I think there is no trademark issue, but "git-dag" is probably just
not a great idea in general, because the namespace is open and it is
likely to get stomped by some other project. Or git itself. Or it may
even be annoying for users who have a "git dag" alias (on-disk commands
always override aliases).

So I think we should generally recommend against such generic names
during the naming phase. At this point, I'm not sure the pain of
changing now is any less than the pain of changing later if and when
there's a conflict.

I think I'm actually violently agreeing with you, but I wanted to make
it clear. :) (And everything else in your email seemed sensible, too).

-Peff

Re: [PATCH v2 2/6] test-reach: add run_three_modes method

[SZEDER Gábor]

On Mon, Sep 17, 2018 at 09:08:44PM -0700, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee 
> 
> The 'test_three_modes' method assumes we are using the 'test-tool
> reach' command for our test. However, we may want to use the data
> shape of our commit graph and the three modes (no commit-graph,
> full commit-graph, partial commit-graph) for other git commands.
> 
> Split test_three_modes to be a simple translation on a more general
> run_three_modes method that executes the given command and tests
> the actual output to the expected output.
> 
> While inspecting this code, I realized that the final test for
> 'commit_contains --tag' is silently dropping the '--tag' argument.
> It should be quoted to include both.

Nit: while quoting the function's arguments does fix the issue, it
leaves the tests prone to the same issue in the future.  Wouldn't it
be better to use $@ inside the function to refer to all its arguments?


> Signed-off-by: Derrick Stolee 
> ---
>  t/t6600-test-reach.sh | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/t/t6600-test-reach.sh b/t/t6600-test-reach.sh
> index d139a00d1d..1b18e12a4e 100755
> --- a/t/t6600-test-reach.sh
> +++ b/t/t6600-test-reach.sh
> @@ -53,18 +53,22 @@ test_expect_success 'setup' '
>   git config core.commitGraph true
>  '
>  
> -test_three_modes () {
> +run_three_modes () {
>   test_when_finished rm -rf .git/objects/info/commit-graph &&
> - test-tool reach $1 actual &&
> + $1 actual &&
>   test_cmp expect actual &&
>   cp commit-graph-full .git/objects/info/commit-graph &&
> - test-tool reach $1 actual &&
> + $1 actual &&
>   test_cmp expect actual &&
>   cp commit-graph-half .git/objects/info/commit-graph &&
> - test-tool reach $1 actual &&
> + $1 actual &&
>   test_cmp expect actual
>  }
>  
> +test_three_modes () {
> + run_three_modes "test-tool reach $1"
> +}
> +
>  test_expect_success 'ref_newer:miss' '
>   cat >input <<-\EOF &&
>   A:commit-5-7
> @@ -219,7 +223,7 @@ test_expect_success 'commit_contains:hit' '
>   EOF
>   echo "commit_contains(_,A,X,_):1" >expect &&
>   test_three_modes commit_contains &&
> - test_three_modes commit_contains --tag
> + test_three_modes "commit_contains --tag"
>  '
>  
>  test_expect_success 'commit_contains:miss' '
> -- 
> gitgitgadget
> 

Re: Cannot negate `*` ignore pattern for directory with space in the name

[Duy Nguyen]

On Tue, Sep 18, 2018 at 6:13 AM Victor Engmark
 wrote:
>
> To reproduce (from ):
>
> $ cd "$(mktemp --directory)"
> $ mkdir foo\ bar
> $ touch foo\ bar/test
> $ git init
> Initialized empty Git repository in /tmp/tmp.iGmBR6y2xR/.git/
> $ git status --short
> ?? foo bar/
> $ cat > .gitignore << EOF
> > *
> > !foo bar
> > !foo\ bar
> > !"foo bar"

No need to quote, either with double quotes or backslashes. They are
interpreted as literal " and \

> $ git status --short
> [no output]

It's not exactly a bug, more like a trap. '*' matches anything, at
every level. So even if you negate 'foo bar', when we check 'foo
bar/test', '*' pattern applies again and ignores 'foo bar/test'. If
the first line in .gitignore is /* instead of * (to keep match
anything at the top level directory only), then it should work.
-- 
Duy

Re: [PATCH] t3701-add-interactive: tighten the check of trace output

[Taylor Blau]

On Mon, Sep 10, 2018 at 10:18:34AM -0400, Taylor Blau wrote:
> Signed-off-by: Taylor Blau 

Oops, this should be:

  Reviewed-by: Taylor Blau 

Thanks,
Taylor

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

[Jeff King]

On Mon, Sep 17, 2018 at 12:48:51PM -0700, Junio C Hamano wrote:

> Jonathan Nieder  writes:
> 
> > I'd rather that we revert this change altogether.  I have nothing
> > against a convenient command to do this kind of non build related
> > cleanup, but it shouldn't be spelled as "make clean".
> 
> OK, let's do this for now as I wanted to merge the remainder to
> 'master' today.
> 
> -- >8 --
> Subject: Revert "doc/Makefile: drop doc-diff worktree and temporary files on 
> "make clean""
> 
> This reverts commit 6f924265a0bf6efa677e9a684cebdde958e5ba06, which
> started to require that we have an executable git available in order
> to say "make clean", which gives us a chicken-and-egg problem.
> 
> Having to have Git installed, or be in a repository, in order to be
> able to run an optional "doc-diff" tool is fine.  Requiring either
> in order to run "make clean" is a different story.

Yeah, this seems like the best solution. We started with "can we just rm
-rf the temporary directory as part of 'make clean'", which is totally
sensible and matches the other bits there. But then it got more
complicated. :)

People who use doc-diff can still use "doc-diff --clean", so I don't
think much is lost.

Thanks.

-Peff

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

[Jeff King]

On Mon, Sep 17, 2018 at 08:41:36PM +0200, Duy Nguyen wrote:

> > I think the reflog approach has been successful: give these intermediate
> > states a name. So in theory I could do something like:
> >
> >   git checkout -p :@{2.minutes.ago}
> >
> > though it would probably be useful to be able to walk the states, too,
> > just like we have "log --reflog-walk".
> >
> > The syntax above is off-the-cuff (and based on the ":" index
> > syntax). I guess if we had a separate log for "stuff in the worktree
> > that got thrown away by reset" we might need a separate syntax.
> 
> I'm leaning towards reflog too. Not because of the syntax but because
> of reusing the current code base. I don't have to worry about pruning,
> walking, gc-ing... because it's pretty much already there. And the UI
> is not so urgent since reflog file is very readable, early adopters
> can just open the file and get the hash.

Ah, good point on pruning/gc. I had imagined a new "index log" format.
But really if you just turn the result into a tree, then it becomes just
another ref(log). That might be slightly less efficient, but the
flexibility and simplicity are probably worth it. Or maybe with
cache-tree it is not even less efficient.

So that definitely seems like the right direction.

> I'm trying to quickly make something that writes to
> "$GIT_DIR/logs/index" and see how it goes. But yeah I'll probably drop
> this patch. The ":@{2.minutes.ago}" just makes me like this direction
> more, even though I don't know if I could even make that work.

I think "index@{2.minutes.ago}" would almost work, but it would probably
complain about a reflog without a matching ref. That seems like it would
be pretty easy to work around in the reflog code. Or maybe even by
having a stash-like "index log" ref.

-Peff

[PATCH] add: do not accept pathspec magic 'attr'

[Nguyễn Thái Ngọc Duy]

Commit b0db704652 (pathspec: allow querying for attributes -
2017-03-13) adds new pathspec magic 'attr' but only with
match_pathspec(). "git add" has some pathspec related code that still
does not know about 'attr' and will bail out:

$ git add ':(attr:foo)'
fatal: BUG:dir.c:1584: unsupported magic 40

A better solution would be making this code support 'attr'. But I
don't know how much work is needed (I'm not familiar with this new
magic). For now, let's simply reject this magic with a friendlier
message:

$ git add ':(attr:foo)'
fatal: :(attr:foo): pathspec magic not supported by this command: 'attr'

Reported-by: smau...@sebastianaudet.com
Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Since Brandon is currently unreachable, let's do this for now. I
 might eventually find time to go over pathspec code and see if I can
 add 'attr' support to the rest of the commands, but no promise.

 builtin/add.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/add.c b/builtin/add.c
index 9916498a29..0b64bcdebe 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -454,7 +454,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 * Check the "pathspec '%s' did not match any files" block
 * below before enabling new magic.
 */
-   parse_pathspec(, 0,
+   parse_pathspec(, PATHSPEC_ATTR,
   PATHSPEC_PREFER_FULL |
   PATHSPEC_SYMLINK_LEADING_PATH,
   prefix, argv);
-- 
2.19.0.rc0.337.ge906d732e7

Re: [PATCH 2/3] gc: exit with status 128 on failure

[Jeff King]

On Mon, Sep 17, 2018 at 11:40:12AM -0700, Jonathan Nieder wrote:

> > There's discussion elsewhere[1] of applying just up to patch 2.
> >
> > Do we still want to convert these cases to die() as their end-state?
> 
> IMHO yes, we do.  die() is the function that you can use to exit with
> a fatal error.
> 
> If we want to get rid of die(), that would be a tree-wide effort, not
> something that should hold up this patch.

But that was sort of my question. I think there are people who _do_ want
to get rid of most die() calls (like Dscho), and there is a tree-wide
effort that is happening slowly to lib-ify. Your patch goes in the
opposite direction.

That said, I think there are actually two cases in your patch.

The calls to "return error()" or even just "return -1" in cmd_gc() seem
like obvious candidates for die(). We're at the top of the stack, and
anybody lib-ifying at that level is going to need to extract bits into
reusable functions anyway.

I more wondered about helpers like report_last_gc_error() and
gc_before_repack().

> > It also makes the code more flexible and lib-ifiable (since the caller
> > can decide how to handle the errors). That probably doesn't matter much
> > since this is all static-local to builtin/gc.c,
> 
> Exactly.  I'm a strong believer in http://wiki.c2.com/?YouArentGonnaNeedIt.

I only half-agree that this is YAGNI. If it were "let's punt on making
this code friendlier to lib-ification", I'd agree more completely. But
it's actually taking an active step in the opposite direction.

I dunno. It's probably not worth spending too much more time discussing,
and I'm OK either way.  I mostly just wanted to raise the issue since
dropping patch 3 changes the balance to me.

-Peff

Re: [PATCH] config doc: add missing list separator for checkout.optimizeNewBranch

[Taylor Blau]

On Tue, Sep 18, 2018 at 01:16:43PM -0400, Jeff King wrote:
> On Tue, Sep 18, 2018 at 12:57:07PM -0400, Taylor Blau wrote:
>
> > Hi Ævar,
> >
> > On Tue, Sep 18, 2018 at 05:34:49AM +, Ævar Arnfjörð Bjarmason wrote:
> > > The documentation added in fa655d8411 ("checkout: optimize "git
> > > checkout -b "", 2018-08-16) didn't add the double-colon
> > > needed for the labeled list separator, as a result the added
> > > documentation all got squashed into one paragraph. Fix that by adding
> > > the list separator.
> >
> > Looks good. Here's my:
> >
> >   Signed-off-by: Taylor Blau 
>
> I'm confused here. The signoff is really about agreeing publicly to the
> DCO, and providing a chain of custody for the changes. So sometimes a
> signoff from somebody besides the patch author is good if they
> contributed content to the patch, but I don't see that here (or in any
> nearby thread).
>
> Did you mean "Reviewed-by:" ?

Indeed, I meant "Reviewed-by" instead of "Signed-off-by". I grok the
difference between the two, but without thinking about it I typed one
instead of the other.

Instead, here's my Reviewed-by:

  Reviewed-by: Taylor Blau 

Thanks,
Taylor

Re: [PATCH] config doc: add missing list separator for checkout.optimizeNewBranch

[Jeff King]

On Tue, Sep 18, 2018 at 12:57:07PM -0400, Taylor Blau wrote:

> Hi Ævar,
> 
> On Tue, Sep 18, 2018 at 05:34:49AM +, Ævar Arnfjörð Bjarmason wrote:
> > The documentation added in fa655d8411 ("checkout: optimize "git
> > checkout -b "", 2018-08-16) didn't add the double-colon
> > needed for the labeled list separator, as a result the added
> > documentation all got squashed into one paragraph. Fix that by adding
> > the list separator.
> 
> Looks good. Here's my:
> 
>   Signed-off-by: Taylor Blau 

I'm confused here. The signoff is really about agreeing publicly to the
DCO, and providing a chain of custody for the changes. So sometimes a
signoff from somebody besides the patch author is good if they
contributed content to the patch, but I don't see that here (or in any
nearby thread).

Did you mean "Reviewed-by:" ?

-Peff

Re: [PATCH v5 9/9] submodule: support reading .gitmodules when it's not in the working tree

[SZEDER Gábor]

Hi Antonio,

it appears that this patch (and its previous versions as well) is
responsible for triggering occasional test failures in
't7814-grep-recurse-submodules.sh', more frequently, about once in
every ten runs, on macOS on Travis CI, less frequently, about once in
a couple of hundred runs on Linux on my machine.

The reason for the failure is memory corruption manifesting in various
ways: segfault, malloc() or use after free() errors from libc, corrupt
loose object, invalid ref, bogus output, etc.

Applying the following patch makes t7814 fail almost every time,
though sometimes that loop has to iterate over 1000 times until that
'git grep' finally fails...  so good luck with debugging ;)

diff --git a/t/t7814-grep-recurse-submodules.sh 
b/t/t7814-grep-recurse-submodules.sh
index 7184113b9b..93ae2e8e7c 100755
--- a/t/t7814-grep-recurse-submodules.sh
+++ b/t/t7814-grep-recurse-submodules.sh
@@ -337,6 +337,10 @@ test_expect_success 'grep --recurse-submodules should pass 
the pattern type alon
test_must_fail git -c grep.patternType=fixed grep --recurse-submodules 
-e "(.|.)[\d]" &&
 
# Basic
+   for i in $(seq 0 2000)
+   do
+   git grep --recurse-submodules 1 >/dev/null || return 1
+   done &&
git grep -G --recurse-submodules -e "(.|.)[\d]" >actual &&
cat >expect <<-\EOF &&
a:(1|2)d(3|4)


On first look I didn't notice anything that is obviously wrong in this
patch and could be responsible for the memory corruption, but there is
one thing I found strange, though:


On Mon, Sep 17, 2018 at 04:09:40PM +0200, Antonio Ospite wrote:
> When the .gitmodules file is not available in the working tree, try
> using the content from the index and from the current branch.

"from the index and from the current branch" of which repository?

> This
> covers the case when the file is part of the repository but for some
> reason it is not checked out, for example because of a sparse checkout.
> 
> This makes it possible to use at least the 'git submodule' commands
> which *read* the gitmodules configuration file without fully populating
> the working tree.
> 
> Writing to .gitmodules will still require that the file is checked out,
> so check for that before calling config_set_in_gitmodules_file_gently.
> 
> Add a similar check also in git-submodule.sh::cmd_add() to anticipate
> the eventual failure of the "git submodule add" command when .gitmodules
> is not safely writeable; this prevents the command from leaving the
> repository in a spurious state (e.g. the submodule repository was cloned
> but .gitmodules was not updated because
> config_set_in_gitmodules_file_gently failed).
> 
> Finally, add t7416-submodule-sparse-gitmodules.sh to verify that reading
> from .gitmodules succeeds and that writing to it fails when the file is
> not checked out.
> 
> Signed-off-by: Antonio Ospite 
> ---

> diff --git a/submodule-config.c b/submodule-config.c
> index 61a555e920..bdb1d0e2c9 100644
> --- a/submodule-config.c
> +++ b/submodule-config.c

> @@ -603,8 +604,21 @@ static void submodule_cache_check_init(struct repository 
> *repo)
>  static void config_from_gitmodules(config_fn_t fn, struct repository *repo, 
> void *data)
>  {
>   if (repo->worktree) {
> - char *file = repo_worktree_path(repo, GITMODULES_FILE);
> - git_config_from_file(fn, file, data);
> + struct git_config_source config_source = { 0 };
> + const struct config_options opts = { 0 };
> + struct object_id oid;
> + char *file;
> +
> + file = repo_worktree_path(repo, GITMODULES_FILE);
> + if (file_exists(file))
> + config_source.file = file;
> + else if (get_oid(GITMODULES_INDEX, ) >= 0)
> + config_source.blob = GITMODULES_INDEX;

The repository used in t7814 contains nested submodules, which means
that config_from_gitmodules() is invoked three times.

Now, the first two of those calls look at the superproject and at
'submodule', and find the existing files '.../trash
directory.t7814-grep-recurse-submodules/.gitmodules' and '.../trash
directory.t7814-grep-recurse-submodules/submodule/.gitmodules',
respectively.  So far so good.

The third call, however, looks at the nested submodule at
'submodule/sub', which doesn't contain a '.gitmodules' file.  So this
function goes on with the second condition and calls
get_oid(GITMODULES_INDEX, ), which then appears to find the blob
in the _superproject's_ index.

I'm no expert on submodules, but my gut feeling says that this can't
be right.  But if it _is_ right, then I would say that the commit
message should explain in detail, why it is right.

Anyway, even if it is indeed wrong, I'm not sure whether this is the
root cause of the memory corruption.


> + else if (get_oid(GITMODULES_HEAD, ) >= 0)
> + config_source.blob = GITMODULES_HEAD;
> +
> + config_with_options(fn, 

Re: [PATCH] config doc: add missing list separator for checkout.optimizeNewBranch

[Jeff King]

On Tue, Sep 18, 2018 at 05:34:49AM +, Ævar Arnfjörð Bjarmason wrote:

> The documentation added in fa655d8411 ("checkout: optimize "git
> checkout -b "", 2018-08-16) didn't add the double-colon
> needed for the labeled list separator, as a result the added
> documentation all got squashed into one paragraph. Fix that by adding
> the list separator.

Obviously the right thing to do, but your patch does not seem to apply
on that commit. Looks like you built it on a more recent commit that
also has checkout.defaultRemote (i.e., probably 'next')?

> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ac71ade256..1546833213 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1153,7 +1153,7 @@ and by linkgit:git-worktree[1] when 'git worktree add' 
> refers to a
>  remote branch. This setting might be used for other checkout-like
>  commands or functionality in the future.
>  
> -checkout.optimizeNewBranch
> +checkout.optimizeNewBranch::
>   Optimizes the performance of "git checkout -b " when
>   using sparse-checkout.  When set to true, git will not update the
>   repo based on the current sparse-checkout settings.  This means it

Now the real reason I responded. :)

I just want to plug the recently-added "doc-diff" script, which diffs a
rendered view and makes it easier to catch cases like this. E.g., after
applying your patch:

  $ cd Documentation
  $ ./doc-diff HEAD^ HEAD
  [...]
  diff --git 
a/6ad88fd5d99b8dcbb69c6f3239ad41e66516d8f7/none/share/man/man1/git-config.1 
b/28e258682021a09cd7842e4edbb21ad231c8bb7a/none/share/man/man1/git-config.1
  index 7298292112..fa91b5f2d1 100644
  --- 
a/6ad88fd5d99b8dcbb69c6f3239ad41e66516d8f7/none/share/man/man1/git-config.1
  +++ 
b/28e258682021a09cd7842e4edbb21ad231c8bb7a/none/share/man/man1/git-config.1
  @@ -1533,12 +1533,13 @@ CONFIGURATION FILE
  branch. This setting might be used for other checkout-like 
commands
  or functionality in the future.
   
  -   checkout.optimizeNewBranch Optimizes the performance of "git checkout
  -   -b " when using sparse-checkout. When set to true, git 
will
  -   not update the repo based on the current sparse-checkout settings. 
This
  -   means it will not update the skip-worktree bit in the index nor
  -   add/remove files in the working directory to reflect the current 
sparse
  -   checkout settings nor will it show the local changes.
  +   checkout.optimizeNewBranch
  +   Optimizes the performance of "git checkout -b " when
  +   using sparse-checkout. When set to true, git will not update the
  +   repo based on the current sparse-checkout settings. This means it
  +   will not update the skip-worktree bit in the index nor add/remove
  +   files in the working directory to reflect the current sparse
  +   checkout settings nor will it show the local changes.
   
  clean.requireForce
  A boolean to make git-clean do nothing unless given -f, -i or -n.

Obviously we knew this fix was going to help, but running it on the
original fa655d8411 (versus its parent) and eyeballing the result might
have caught this sooner.

(Though I would not be at all surprised to hear that the script does not
run on Windows, as it relies on things like "man"; patches certainly
welcome).

-Peff

Re: [PATCH] config doc: add missing list separator for checkout.optimizeNewBranch

[Taylor Blau]

Hi Ævar,

On Tue, Sep 18, 2018 at 05:34:49AM +, Ævar Arnfjörð Bjarmason wrote:
> The documentation added in fa655d8411 ("checkout: optimize "git
> checkout -b "", 2018-08-16) didn't add the double-colon
> needed for the labeled list separator, as a result the added
> documentation all got squashed into one paragraph. Fix that by adding
> the list separator.

Looks good. Here's my:

  Signed-off-by: Taylor Blau 

Thanks,
Taylor

Re: Hash algorithm analysis

[Linus Torvalds]

On Tue, Sep 18, 2018 at 8:18 AM Joan Daemen  wrote:
>
> 3) The relatively large state in the sponge construction increases the 
> generic strength against attacks when the input contains redundancy or
> has a certain form. For instance, if the input is restricted to be text in 
> ASCII (such as source code), then the collision-resistance grows
> higher than the nominal 2^{c/2}. Such an effect does not exist with 
> narrow-pipe Merkle-Damgård. (This may be what Linus had intuitively in mind.)

Answering to just this part:

No, what I had in mind was literally just exactly the kind of attack
that SHA1 broke for - attacking the internal state vector directly,
and not paying any penalty for it, because the stat size is the same
as the final hash size.

The length extension attack is just the simplest and most trivial
version of that kind of attack - because the internal state vector
*is* the result, and you just continue using it.

But that trivial length extension thing not the real problem, it's
just the absolutely simplest symptom of the real problem.

I think that the model where the internal state of the hash is the
same width as the final result is simply broken. It was what broke
SHA1, and that problem is shared with SHA2.

"Length extension" is just the simplest way to say "broken by design", imho.

Because the length extension attack is just the most trivial attack,
but it isn't the fundamental problem. It was just the first and the
cheapest attack found, but it was also the most special-cased and
least interesting. You need to have a very special case (with that
secret at the beginning etc) to make the pure length extension attack
interesting. And git has no secrets, so in that sense "length
extension" by itself is totally immaterial. But the basic problem of
internal hash size obviously wasn't.

So I would say that length extension is a direct result of the _real_
problem, which is that the hash exposes _all_ of the internal data.

That is what makes length extension possible - because you can just
continue from a known state, and there is absolutely nothing hidden -
and yes, that's a really easy special case where you don't even need
to actually break the hash at all.

But I argue that it's _also_ one big part of what made SHAttered
practical, and I think the underlying problem is exactly the same.
When the internal state is the same size as the hash, you can attack
the internal state itself for basically the same cost as attacking the
whole hash.

So you can pick-and-choose the weakest point.

Which is basically exactly what SHAttered did. No, it wasn't the
trivial "just add to the end", but it used the exact same underlying
weakness as one part of the attack.

*This* is why I dislike SHA2. It has basically the exact same basic
weakness that we already know SHA1 fell for. The hashing details are
different, and hopefully that means that there aren't the same kind of
patterns that can be generated to do the "attack the internal hash
state" part, but I don't understand why people seem to ignore that
other fundamental issue.

Something like SHA-512/256 would have been better, but I think almost
nobody does that in hardware, which was one of the big advantages of
plain SHA2.

The main reason I think SHA2 is acceptable is simply that 256 bits is
a lot. So even if somebody comes up with a shortcut that weakens it by
tens of bits, nobody really cares. Plus I'm obviously not a
cryptographer, so I didn't feel like I was going to fight it a lot.

But yes, I'd have probably gone with any of the other alternatives,
because I think it's a bit silly that we're switching hashes to
another hash that has (at least in part) the *exact* same issue as the
one people call broken.

(And yes, the hashing details are different, so it's "exactly the
same" only wrt that internal state part - not the bitpattern finding
part that made the attack on the internal state much cheaper. Real
cryptographers obviously found that "figure out the weakness of the
hashing" to be the more interesting and novel part over the trivial
internal hash size part).

That said..

The real reason I think SHA2 is the right choice was simply that there
needs to be a decision, and none of the choices were *wrong*.
Sometimes just the _act_ of making a decision is more important than
_what_ the decision is.

And hey, it is also likely that the reason _I_ get hung up on just the
size of the internal state is that exactly because I am _not_ a
cryptographer, that kind of high-level stuff is the part I understand.
When you start talking about why the exact rules of Merkle–Damgård
constructions work, my eyes just glaze over.

So I'm probably - no, certainly - myopic and looking at only one part
of the issue to begin with.

The end result is that I argued for more bits in the internal state
(and apparently wide vs narrow is the technical term), and I would
have seen parallel algorithms as a bonus for the large-file case. None
of which argued for SHA2.

But 

Re: Hash algorithm analysis

[Jonathan Nieder]

Hi,

A quick note.

Joan Daemen wrote:

> when going over my todo list I was confronted with the mail of Dan
> Shumow on the successor of SHA-1 for git. I know the decision was
> made and it is not my intention to change it, but please see below
> some comments on Dan's arguments.

When the time comes for the next hash change in Git, it will be useful
to be able to look back over this discussion.  Thanks for adding
details.

[...]
> On 30/07/2018 22:01, Dan Shumow wrote:

>> So, I also want to state my biases in favor of SHA2 as an employee
>> of Microsoft. [...] As such, and reflecting this bias, in the
>> internal discussions that Johannes alluded to, SHA2 and SHA3 were
>> the primary suggestions.  There was a slight preference for SHA2
>> because SHA3 is not exposed through the windows cryptographic APIs
>> (though Git does not use those, so this is a nonissue for this
>> discussion.)
>
> We find it cynical to bring up a Microsoft-internal argument that is
> actually not relevant to Git.

On the contrary, I am quite grateful that Dan was up front about where
his preference comes from, *especially* when the reasons are not
relevant to Git.  It is useful background for better understanding his
rationale and understanding the ramifications for some subset of
users.

In other words, consider someone active in the Git project that
disagrees with the decision to use SHA2.  This explanation by Dan can
help such a person understand where the disagreement is coming from
and whether we are making the decision for the wrong reasons (because
Git on Windows does not even use those APIs).

[...]
> 3) The relatively large state in the sponge construction increases
> the generic strength against attacks when the input contains
> redundancy or has a certain form. For instance, if the input is
> restricted to be text in ASCII (such as source code), then the
> collision-resistance grows higher than the nominal 2^{c/2}. Such an
> effect does not exist with narrow-pipe Merkle-Damgård. (This may be
> what Linus had intuitively in mind.)

Interesting.

[...]
> [2] Daniel J. Bernstein, Cost analysis of hash collisions: Will
> quantum computers make SHARCS obsolete? Workshop Record of
> SHARCS'09.

I remember that paper!  Thanks for the pointer.

Sincerely,
Jonathan

Re: Hash algorithm analysis

[Joan Daemen]

Dear all,

when going over my todo list I was confronted with the mail of Dan Shumow on 
the successor of SHA-1 for git. I know the decision was made and it is not my 
intention to change it, but please see below some comments on Dan's arguments.

In short, I argue below that SHA256 has no serious advantages when compared to 
KangarooTwelve. In that light, the fact that SHA2 was designed behind closed 
doors (like SHA-1 was) should be enough reason to skip it entirely in an 
undertaking that takes open-source seriously.

Kind regards,

Joan

PS: In my comments below I use "we" as I discussed them with the members of the 
Keccak team being Gilles Van Assche, Michaël Peeters, Guido Bertoni, Ronny Van 
Keer and Seth Hoffert, and we agree on all of them.

On 30/07/2018 22:01, Dan Shumow wrote:
> Hello all.   Johannes, thanks for adding me to this discussion.
>
> So, as one of the coauthors of the SHA-1 collision detection code, I just 
> wanted to chime in and say I'm glad to see the move to a longer hash 
> function.  Though, as a cryptographer, I have a few thoughts on the matter 
> that I thought I would share.
>
> I think that moving to SHA256 is a fine change, and I support it.
>
> I'm not anywhere near the expert in this that Joan Daeman is. 

Note that the correct spelling is "Daemen". But anyway, it is not a matter of 
being expert, but a matter of taking the arguments at face value. 

> I am someone who has worked in this space more or less peripherally.  
> However, I agree with Adam Langley that basically all of the finalists for a 
> hash function replacement are about the same for the security needs of Git.  
> I think that, for this community, other software engineering considerations 
> should be more important to the selection process.

We are also with Adam on the engineering considerations. We see the parallelism 
that K12 can exploit adaptively (unlike SHA256) as an example of such a 
consideration.

> I think Joan's survey of cryptanalysis papers and the numbers that he gives 
> are interesting, and I had never seen the comparison laid out like that.  So, 
> I think that there is a good argument to be made that SHA3 has had more 
> cryptanalysis than SHA2.  Though, Joan, are the papers that you surveyed only 
> focused on SHA2?  I'm curious if you think that the design/construction of 
> SHA2, as it can be seen as an iteration of MD5/SHA1, means that the 
> cryptanalysis papers on those constructions can be considered to apply to 
> SHA2?  

This argument works both ways, i.e., the knowledge and experience of the 
symmetric cryptography community in general has also contributed to our choices 
in Keccak and in K12 (including the experience gained by Rijndael/AES). But in 
the end, the only objective metric we have for comparing public scrutiny is the 
amount of cryptanalysis (and analysis) published, and there Keccak simply 
scores better.

> Again, I'm not an expert in this, but I do know that Marc Steven's techniques 
> for constructing collisions also provided some small cryptanalytic 
> improvements against the SHA2 family as well.  I also think that while the 
> paper survey is a good way to look over all of this, the more time in the 
> position of high profile visibility that SHA2 has can give us some confidence 
> as well.

High profile visibility to implementers does not mean more cryptanalysis, since 
users and implementers are usually not cryptanalysts. Actually, one of the 
reasons that SHA2 attracted much less cryptanalysis than you would expect due 
to its age is that during the SHA3 competition all cryptanalysts pointed their 
arrows to SHA3 candidates.

> Also something worth pointing out is that the connection SHA2 has to SHA1 
> means that if Marc Steven's cryptanalysis of MD5/SHA-1 were ever successfully 
> applied to SHA2, the SHA1 collision detection approach could be applied there 
> as well, thus providing a drop in replacement in that situation.  That said, 
> we don't know that there is not a similar way of addressing issues with the 
> SHA3/Sponge design.  It's just that because we haven't seen any weaknesses of 
> this sort in similar designs, we just don't know what a similar approach 
> would be there yet.  I don't want to put too much stock in this argument, 
> it's just saying "Well, we already know how SHA2 is likely to break, and 
> we've had fixes for similar things in the past."  This is pragmatic but not 
> inspiring or confidence building.
>
> So, I also want to state my biases in favor of SHA2 as an employee of 
> Microsoft.  Microsoft, being a corporation headquartered in a America, with 
> the US Gov't as a major customer definitely prefers to defer to the US Gov't 
> NIST standardization process.  And from that perspective SHA2 or SHA3 would 
> be good choices.  I, personally, think that the NIST process is the best we 
> have.  It is relatively transparent, and NIST employs a fair number of very 
> competent cryptographers.  Also, I am encouraged 

Contact this Email for your payment; info...@consultant.com

[UBA CONSULTANT]

   This is to officially inform you that we have verified your contract 
file presently on my desk, and I found out that you have not received 
your payment due to your lack of co-operation and not fulfilling the 
obligations giving to you in respect to your contract payment.Secondly, 
you are hereby advised to stop dealing with some non-officials in the 
bank as this is an illegal act and will have to stop if you so wish to 
receive your payment after the board of director's meeting held in 
Burkina Faso, we have resolved in finding a solution to your problem.

 We have arranged your payment through our atm card payment center in 
europe, america, africa and asia pacific; this is part of an 
instruction/mandate passed by the senate in respect to overseas 
contract payment and debt re-scheduling. We will send you an atm card 
which you will use to withdraw your money via atm machine in any part 
of the world, and the maximum daily limit is two thousand united states 
dollars($2,000.00) valued sum of five million united states dollars 
($5m), if you desire to receive your fund this way, kindly re-confirm 
your info:


Thanks for your understanding.

Mrs Selin UBA Manager
Contact this Email for your payment; info...@consultant.com

[PATCH 1/1] git-rebase--interactive.sh: fix trailing spaces on empty $todo

[Shulhan]

When issuing interactive rebase, git will open a text editor with list
of commits to rebase and documentation on how to edit it.  At the end
of documentation it display,

  # However, if you remove everything, the rebase will be aborted.
  #
  #\t
  # Note that empty commits are commented out

The "\t" is white space tab.

This commit remove the empty tab at the last two line.
---
 git-rebase--interactive.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 299ded213..0bf9eefad 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -224,7 +224,7 @@ EOF
gettext "
However, if you remove everything, the rebase will be aborted.
 
-   " | git stripspace --comment-lines >>"$todo"
+" | git stripspace --comment-lines >>"$todo"
 
if test -z "$keep_empty"
then
-- 
2.19.0.446.g26223adc4

[PATCH 0/1] git-rebase--interactive.sh: fix trailing spaces on empty $todo

[Shulhan]

For someone who use editor that display trailing white spaces, issuing
interactive rebase will print two empty lines at the end of rebase with the
last line contains tab,

  # However, if you remove everything, the rebase will be aborted.
  #
  #\t
  # Note that empty commits are commented out

The character "\t" in above example is white space tab.

The "make test" was run succesfully but I can't reproduce/test manually with
non-empty $todo (I have no idea how to do it).

Shulhan (1):
  git-rebase--interactive.sh: fix trailing spaces on empty $todo

 git-rebase--interactive.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.19.0.446.g26223adc4

Re: [PATCH 3/3] fetch doc: correct grammar in --force docs

[Eric Sunshine]

On Tue, Sep 18, 2018 at 1:48 AM Ævar Arnfjörð Bjarmason
 wrote:
> "Work the same" is incorrect and needs to be "Works the same
> way". Fixes grammar in document anion I added in the recently landed

I, too, find those "document anions" problematic. Perhaps the
physicists around here can do something about it.

> 0bc8d71b99 ("fetch: stop clobbering existing tags without --force",
> 2018-08-31).
>
> Signed-off-by: Ævar Arnfjörð Bjarmason 

Re: [PATCH v2 0/6] Use generation numbers for --topo-order

[Ævar Arnfjörð Bjarmason]

On Tue, Sep 18 2018, Derrick Stolee via GitGitGadget wrote:

Thanks. Good to see the commit graph used for more stuff.

> On the Linux repository, I got the following performance results when
> comparing to the previous version with or without a commit-graph:
>
> Test: git rev-list --topo-order -100 HEAD
> HEAD~1, no commit-graph: 6.80 s
> HEAD~1, w/ commit-graph: 0.77 s
>   HEAD, w/ commit-graph: 0.02 s
>
> Test: git rev-list --topo-order -100 HEAD -- tools
> HEAD~1, no commit-graph: 9.63 s
> HEAD~1, w/ commit-graph: 6.06 s
>   HEAD, w/ commit-graph: 0.06 s

It would be great if this were made into a t/perf/ test shipped with
this series, that would be later quoted in a commit, as in
e.g. 3b41fb0cb2 ("fsck: use oidset instead of oid_array for skipList",
2018-09-03).

Although generalizing that "-- tools" part (i.e. finding a candidate
dir) will require some heuristic, but would make it useful when running
this against other erpos.

> If you want to read this series but are unfamiliar with the commit-graph and
> generation numbers, then I recommend reading
> Documentation/technical/commit-graph.txt or a blob post [1] I wrote on the
> subject. In particular, the three-part walk described in "revision.c:
> refactor basic topo-order logic" is present (but underexplained) as an
> animated PNG [2].

We discussed some of this in private E-Mail, and this isn't really
feedback on *this* series in particular, just on the general
commit-graph work.

Right now git-config(1) just matter-of-factly says how to enable it, and
points to git-commit-graph(1) for further info, which just shows how to
run the tool. But nothing's describing what stuff is sped up, and those
sorts of docs aren't being updated as new optimizations (e.g. this
--topo-order walk) are added.

For that you need to scour a combination of your blogpost & commits in
git.git (with quoted perf numbers).