date:20180726

Re: [PATCH v9 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-07-26 Thread Max Kirillov

Only the 3rd patch has changed

[PATCH v9 3/3] http-backend: respect CONTENT_LENGTH for receive-pack

2018-07-26 Thread Max Kirillov

Push passes to another commands, as described in
https://public-inbox.org/git/20171129032214.gb32...@sigill.intra.peff.net/

As it gets complicated to correctly track the data length, instead transfer
the data through parent process and cut the pipe as the specified length is
reached. Do it only when CONTENT_LENGTH is set, otherwise pass the input
directly to the forked commands.

Add tests for cases:

* CONTENT_LENGTH is set, script's stdin has more data, with all combinations
  of variations: fetch or push, plain or compressed body, correct or truncated
  input.

* CONTENT_LENGTH is specified to a value which does not fit into ssize_t.

Helped-by: Junio C Hamano 
Signed-off-by: Max Kirillov 
---
 help.c |   1 +
 http-backend.c |  32 -
 t/t5562-http-backend-content-length.sh | 155 +
 t/t5562/invoke-with-content-length.pl  |  37 ++
 4 files changed, 223 insertions(+), 2 deletions(-)
 create mode 100755 t/t5562-http-backend-content-length.sh
 create mode 100755 t/t5562/invoke-with-content-length.pl

diff --git a/help.c b/help.c
index dd35fcc133..e469f5731c 100644
--- a/help.c
+++ b/help.c
@@ -609,6 +609,7 @@ int cmd_version(int argc, const char **argv, const char 
*prefix)
else
printf("no commit associated with this build\n");
printf("sizeof-long: %d\n", (int)sizeof(long));
+   printf("sizeof-size_t: %d\n", (int)sizeof(size_t));
/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
}
return 0;
diff --git a/http-backend.c b/http-backend.c
index d0b6cb1b09..e88d29f62b 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -373,6 +373,8 @@ static void inflate_request(const char *prog_name, int out, 
int buffer_input, ss
unsigned char in_buf[8192];
unsigned char out_buf[8192];
unsigned long cnt = 0;
+   int req_len_defined = req_len >= 0;
+   size_t req_remaining_len = req_len;
 
memset(, 0, sizeof(stream));
git_inflate_init_gzip_only();
@@ -387,8 +389,15 @@ static void inflate_request(const char *prog_name, int 
out, int buffer_input, ss
n = read_request(0, _request, req_len);
stream.next_in = full_request;
} else {
-   n = xread(0, in_buf, sizeof(in_buf));
+   ssize_t buffer_len;
+   if (req_len_defined && req_remaining_len <= 
sizeof(in_buf))
+   buffer_len = req_remaining_len;
+   else
+   buffer_len = sizeof(in_buf);
+   n = xread(0, in_buf, buffer_len);
stream.next_in = in_buf;
+   if (req_len_defined && n > 0)
+   req_remaining_len -= n;
}
 
if (n <= 0)
@@ -431,6 +440,23 @@ static void copy_request(const char *prog_name, int out, 
ssize_t req_len)
free(buf);
 }
 
+static void pipe_fixed_length(const char *prog_name, int out, size_t req_len)
+{
+   unsigned char buf[8192];
+   size_t remaining_len = req_len;
+
+   while (remaining_len > 0) {
+   size_t chunk_length = remaining_len > sizeof(buf) ? sizeof(buf) 
: remaining_len;
+   ssize_t n = xread(0, buf, chunk_length);
+   if (n < 0)
+   die_errno("Reading request failed");
+   write_to_child(out, buf, n, prog_name);
+   remaining_len -= n;
+   }
+
+   close(out);
+}
+
 static void run_service(const char **argv, int buffer_input)
 {
const char *encoding = getenv("HTTP_CONTENT_ENCODING");
@@ -457,7 +483,7 @@ static void run_service(const char **argv, int buffer_input)
 "GIT_COMMITTER_EMAIL=%s@http.%s", user, host);
 
cld.argv = argv;
-   if (buffer_input || gzipped_request)
+   if (buffer_input || gzipped_request || req_len >= 0)
cld.in = -1;
cld.git_cmd = 1;
if (start_command())
@@ -468,6 +494,8 @@ static void run_service(const char **argv, int buffer_input)
inflate_request(argv[0], cld.in, buffer_input, req_len);
else if (buffer_input)
copy_request(argv[0], cld.in, req_len);
+   else if (req_len >= 0)
+   pipe_fixed_length(argv[0], cld.in, req_len);
else
close(0);
 
diff --git a/t/t5562-http-backend-content-length.sh 
b/t/t5562-http-backend-content-length.sh
new file mode 100755
index 00..057dcb85d6
--- /dev/null
+++ b/t/t5562-http-backend-content-length.sh
@@ -0,0 +1,155 @@
+#!/bin/sh
+
+test_description='test git-http-backend respects CONTENT_LENGTH'
+. ./test-lib.sh
+
+test_lazy_prereq GZIP 'gzip --version'
+
+verify_http_result() {
+   # some fatal errors still produce status 200
+   # so check if there

[PATCH v9 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-07-26 Thread Max Kirillov

* fix the gzip usage as suggested in 
https://public-inbox.org/git/xmqqk1quvegh@gitster-ct.c.googlers.com/
* better explanation of why status check is needed
* redirect only the helper call, not the whole shell function, also move more 
into the shell function

Max Kirillov (3):
  http-backend: cleanup writing to child process
  http-backend: respect CONTENT_LENGTH as specified by rfc3875
  http-backend: respect CONTENT_LENGTH for receive-pack

 config.c   |   2 +-
 config.h   |   1 +
 help.c |   1 +
 http-backend.c | 100 +---
 t/t5562-http-backend-content-length.sh | 155 +
 t/t5562/invoke-with-content-length.pl  |  37 ++
 6 files changed, 281 insertions(+), 15 deletions(-)
 create mode 100755 t/t5562-http-backend-content-length.sh
 create mode 100755 t/t5562/invoke-with-content-length.pl

-- 
2.17.0.1185.g782057d875

[PATCH v9 2/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875

2018-07-26 Thread Max Kirillov

http-backend reads whole input until EOF. However, the RFC 3875 specifies
that a script must read only as many bytes as specified by CONTENT_LENGTH
environment variable. Web server may exercise the specification by not closing
the script's standard input after writing content. In that case http-backend
would hang waiting for the input. The issue is known to happen with
IIS/Windows, for example.

Make http-backend read only CONTENT_LENGTH bytes, if it's defined, rather than
the whole input until EOF. If the variable is not defined, keep older behavior
of reading until EOF because it is used to support chunked transfer-encoding.

This commit only fixes buffered input, whcih reads whole body before
processign it. Non-buffered input is going to be fixed in subsequent commit.

Signed-off-by: Florian Manschwetus 
[mk: fixed trivial build failures and polished style issues]
Helped-by: Junio C Hamano 
Signed-off-by: Max Kirillov 
Signed-off-by: Junio C Hamano 
---
 config.c   |  2 +-
 config.h   |  1 +
 http-backend.c | 54 +++---
 3 files changed, 49 insertions(+), 8 deletions(-)

diff --git a/config.c b/config.c
index fbbf0f8e9f..158afa858b 100644
--- a/config.c
+++ b/config.c
@@ -921,7 +921,7 @@ int git_parse_ulong(const char *value, unsigned long *ret)
return 1;
 }
 
-static int git_parse_ssize_t(const char *value, ssize_t *ret)
+int git_parse_ssize_t(const char *value, ssize_t *ret)
 {
intmax_t tmp;
if (!git_parse_signed(value, , 
maximum_signed_value_of_type(ssize_t)))
diff --git a/config.h b/config.h
index cdac2fc73e..7808413bd0 100644
--- a/config.h
+++ b/config.h
@@ -73,6 +73,7 @@ extern void git_config(config_fn_t fn, void *);
 extern int config_with_options(config_fn_t fn, void *,
   struct git_config_source *config_source,
   const struct config_options *opts);
+extern int git_parse_ssize_t(const char *, ssize_t *);
 extern int git_parse_ulong(const char *, unsigned long *);
 extern int git_parse_maybe_bool(const char *);
 extern int git_config_int(const char *, const char *);
diff --git a/http-backend.c b/http-backend.c
index cefdfd6fc6..d0b6cb1b09 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -290,7 +290,7 @@ static void write_to_child(int out, const unsigned char 
*buf, ssize_t len, const
  * hit max_request_buffer we die (we'd rather reject a
  * maliciously large request than chew up infinite memory).
  */
-static ssize_t read_request(int fd, unsigned char **out)
+static ssize_t read_request_eof(int fd, unsigned char **out)
 {
size_t len = 0, alloc = 8192;
unsigned char *buf = xmalloc(alloc);
@@ -327,7 +327,46 @@ static ssize_t read_request(int fd, unsigned char **out)
}
 }
 
-static void inflate_request(const char *prog_name, int out, int buffer_input)
+static ssize_t read_request_fixed_len(int fd, ssize_t req_len, unsigned char 
**out)
+{
+   unsigned char *buf = NULL;
+   ssize_t cnt = 0;
+
+   if (max_request_buffer < req_len) {
+   die("request was larger than our maximum size (%lu): "
+   "%" PRIuMAX "; try setting GIT_HTTP_MAX_REQUEST_BUFFER",
+   max_request_buffer, (uintmax_t)req_len);
+   }
+
+   buf = xmalloc(req_len);
+   cnt = read_in_full(fd, buf, req_len);
+   if (cnt < 0) {
+   free(buf);
+   return -1;
+   }
+   *out = buf;
+   return cnt;
+}
+
+static ssize_t get_content_length(void)
+{
+   ssize_t val = -1;
+   const char *str = getenv("CONTENT_LENGTH");
+
+   if (str && !git_parse_ssize_t(str, ))
+   die("failed to parse CONTENT_LENGTH: %s", str);
+   return val;
+}
+
+static ssize_t read_request(int fd, unsigned char **out, ssize_t req_len)
+{
+   if (req_len < 0)
+   return read_request_eof(fd, out);
+   else
+   return read_request_fixed_len(fd, req_len, out);
+}
+
+static void inflate_request(const char *prog_name, int out, int buffer_input, 
ssize_t req_len)
 {
git_zstream stream;
unsigned char *full_request = NULL;
@@ -345,7 +384,7 @@ static void inflate_request(const char *prog_name, int out, 
int buffer_input)
if (full_request)
n = 0; /* nothing left to read */
else
-   n = read_request(0, _request);
+   n = read_request(0, _request, req_len);
stream.next_in = full_request;
} else {
n = xread(0, in_buf, sizeof(in_buf));
@@ -381,10 +420,10 @@ static void inflate_request(const char *prog_name, int 
out, int buffer_input)
free(full_request);
 }
 
-static void copy_request(const char *prog_name, int out)
+static void copy_request(const char *prog_name, int out, ssize_t req_len)
 {
unsigned char *buf;
-   ssize_t n =

[PATCH v9 1/3] http-backend: cleanup writing to child process

2018-07-26 Thread Max Kirillov

As explained in [1], we should not assume the reason why the writing has
failed, and even if the reason is that child has existed not the reason
why it have done so. So instead just say that writing has failed.

[1] https://public-inbox.org/git/20180604044408.gd14...@sigill.intra.peff.net/

Signed-off-by: Max Kirillov 
Signed-off-by: Junio C Hamano 
---
 http-backend.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/http-backend.c b/http-backend.c
index adaef16fad..cefdfd6fc6 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -279,6 +279,12 @@ static struct rpc_service *select_service(struct strbuf 
*hdr, const char *name)
return svc;
 }
 
+static void write_to_child(int out, const unsigned char *buf, ssize_t len, 
const char *prog_name)
+{
+   if (write_in_full(out, buf, len) < 0)
+   die("unable to write to '%s'", prog_name);
+}
+
 /*
  * This is basically strbuf_read(), except that if we
  * hit max_request_buffer we die (we'd rather reject a
@@ -361,9 +367,8 @@ static void inflate_request(const char *prog_name, int out, 
int buffer_input)
die("zlib error inflating request, result %d", 
ret);
 
n = stream.total_out - cnt;
-   if (write_in_full(out, out_buf, n) < 0)
-   die("%s aborted reading request", prog_name);
-   cnt += n;
+   write_to_child(out, out_buf, stream.total_out - cnt, 
prog_name);
+   cnt = stream.total_out;
 
if (ret == Z_STREAM_END)
goto done;
@@ -382,8 +387,7 @@ static void copy_request(const char *prog_name, int out)
ssize_t n = read_request(0, );
if (n < 0)
die_errno("error reading request body");
-   if (write_in_full(out, buf, n) < 0)
-   die("%s aborted reading request", prog_name);
+   write_to_child(out, buf, n, prog_name);
close(out);
free(buf);
 }
-- 
2.17.0.1185.g782057d875

Greetings in the name of God, Business proposal in God we trust

2018-07-26 Thread Mrs, Suran Yoda

Greetings in the name of God

Dear Friend


Greetings in the name of God,please let this not sound strange to you
for my only surviving lawyer who would have done this died early this
year.I prayed and got your email id from your country guestbook. I am
Mrs Suran Yoda from London,I am 72 years old,i am suffering from a
long time cancer of the lungs which also affected my brain,from all
indication my conditions is really deteriorating and it is quite
obvious that,according to my doctors they have advised me that i may
not live for the next two months,this is because the cancer stage has
gotten to a very bad stage.I am married to (Dr Andrews Yoda) who
worked with the Embassy of United Kingdom in South

Africa for nine years,Before he died in 2004.

I was bred up from a motherless babies home and was married to my late
husband for Thirty years without a child,my husband died in a fatal
motor accident Before his death we were true believers.Since his death
I decided not to re-marry,I sold all my inherited belongings and
deposited all the sum of $6.5 Million dollars with Bank in South
Africa.Though what disturbs me mostly is the cancer. Having known my
condition I decided to donate this fund to church,i want you as God
fearing person,to also use this money to fund church,orphanages and
widows,I took this decision,before i rest in peace because my time
will so on be up.

The Bible made us to understand that blessed are the hands that
giveth. I took this decision because I don`t have any child that will
inherit this money and my husband's relatives are not Christians and I
don`t want my husband hard earned money to be misused by unbelievers.
I don`t want a situation where these money will be used in an ungodly
manner,hence the reason for taking this bold decision.I am not afraid
of death hence i know where am going.Presently,I'm with my laptop in a
hospital here in London where I have been undergoing treatment for
cancer of the lungs.

As soon as I receive your reply I shall give you the contact of the
Bank.I will also issue you a letter of authority that will prove you
as the new beneficiary of my fund.Please assure me that you will act
accordingly as I stated.Hoping to hear from you soon.

Remain blessed in the name of the Lord.

Yours in Christ,
Mrs Suran Yoda

Re: [PATCH 1/1] add hook pre-p4-submit

2018-07-26 Thread chen bin

Hi, Luke,
Running the hook after applying changes to P4 shadow repo might not be
a good idea.

When the hook is running *before* the changes are applied, I'm 100% sure it's
*only* my code's problem if the hook fails.

One reason we need this hook is sometimes developer is over confident
when applying
some quick one line fix.

The quick fix could be required by business guy before demo to senior
managers or customers.
So we might not want our fix being blocked by upstream commits.

Not everyone is our team is perforce/git expert. Someone only use
`git-p4 submit` and never use
 `git-p4 rebase`. If unit test fails and he could not submit code, he
would come to me for help. But I
want to reduce my workload.


Regards,
Chen


On Fri, Jul 27, 2018 at 7:09 AM, Luke Diamand  wrote:
> On 26 July 2018 at 10:21, Eric Sunshine  wrote:
>> On Wed, Jul 25, 2018 at 10:08 PM chen bin  wrote:
>>> The hook does not receive any information or input from git. The
>>> original requirement
>>> comes from my colleague. He want to run unit test automatically before
>>> submitting code
>>> to remote repository. Or else CI server will send the blame mail to the 
>>> manager.
>>
>> Okay, that seems in line with a hook such as pre-commit. Please do
>> update the documentation to mention that the hook takes no arguments
>> and nothing on standard input, and perhaps describe in the
>> documentation an example use-case (as you did here).
>>
>> I'm not a p4 or git-p4 user, but, out of curiosity, would there be any
>> information which could be supplied to the hook as arguments or
>> standard input (or both) which would help the hook author implement
>> the hook more easily? Perhaps such information would be fodder for a
>> future enhancement (not necessarily needed for this patch).
>
>
> I tried to think of a use-case for a hook requiring any more
> information, but I can't think of any. You're already chdir()'d to the
> P4 shadow repo which is what you really need.
>
> Anything where you just need the commit hash (e.g. checking the commit
> message) can already be done with one of the existing git hooks; I
> don't think git-p4 needs to duplicate that.
>
> And we can't write a commit hook that can know about the Perforce
> changelist, because we don't know what it is yet.
>
> However, looking at the code, it runs the hook at the point just
> *before* the changes are applied to the P4 shadow repo. Would it make
> more sense to run the hook *after* they have been applied (but before
> being P4 submitted) ?
>
> That way you can run your tests on the checked-out P4 shadow directory
> with your changes - as it stands, you can only run them on your git
> repo at this point, which might not be in sync with Perforce (and
> could be quite a long way out in fact).
>
> Luke
>
>
>>
>>> The hook actually stops the submit process from start instead of abort
>>> submit in midway.
>>> So nothing is touched when hook exits with status 1.
>>
>> This might be a good thing to add to the documentation, as well.
>>
>>> I'm not sure whether `git-p4` should print some "hook rejection" message.
>>> Current implementation is same as other hooks (`pre-commit`, for example).
>>> Only hook itself is responsible to print error messages.
>>>
>>> Personally I don't have opinion whether we should print out hook
>>> related message inside
>>> `git-p4.py`. I just try to following existing convention of git.
>>>
>>> What you guys think?
>>
>> Following existing practice makes sense. It can always be revisited
>> later if needed.
>>
>> Thanks.



-- 
help me, help you.

[RFC PATCH 0/3] Migrate the refs API to take the repository argument

2018-07-26 Thread Stefan Beller

The second patch is the real API proposal.
Unlike the lookup_* series, which caused a lot of integration pain to Junio,
I plan to structure this in a different way, by having multiple steps:

 (1) in this (later to be non-RFC) series, add the new API that passes thru
 the repository; for now do not replace refs_store argument by
 struct repository.
 (2) the last patch is a demo of converting one of the callers over
 to the new API; this would need to be done for all of them
 
 (3) After some time do a cleanup series to remove callers of the
 old API fromly introduced series that are currently in flight.
 (4) Remove the old API.

 (5) Introduce the final API removing the refs_store
 (6) convert all callers to the final API, using this same dual step approach
 (7) remove this API
 
Steps 1,2 will be done in this series (2 is done only as demo here
for one function, but the non-RFC would do it all)

Steps 3,4 would be done once there are no more series in flight using
the old API.

Before continuing on step (2), I would want to ask for your thoughts
of (1).

Also note that after step (1) before (4) refs.h looks messy as well as
between (5) and (7).

Thanks,
Stefan


Stefan Beller (3):
  refs.c: migrate internal ref iteration to pass thru repository
argument
  refs: introduce new API, wrap old API shallowly around new API
  replace: migrate to for_each_replace_repo_ref

 builtin/replace.c|   9 +-
 refs.c   | 187 ++
 refs.h   | 362 ++-
 refs/iterator.c  |   6 +-
 refs/refs-internal.h |   5 +-
 replace-object.c |   7 +-
 6 files changed, 464 insertions(+), 112 deletions(-)

-- 
2.18.0.345.g5c9ce644c3-goog

[PATCH 2/3] refs: introduce new API, wrap old API shallowly around new API

2018-07-26 Thread Stefan Beller

Currently the refs API takes a 'ref_store' as an argument to specify
which ref store to iterate over; however it is more useful to specify
the repository instead (or later a specific worktree of a repository).

Introduce a new API, that takes a repository struct instead of a ref store;
the repository argument is also passed through to the callback, which is
of type 'each_repo_ref_fn' that is introduced in a previous patch and is
an extension of the 'each_ref_fn' type with the additional repository
argument.

We wrap the old API as in a very shallow way around the new API,
by wrapping the callback and the callback data into a new callback
to translate between the 'each_ref_fn' and 'each_repo_ref_fn' type.

The wrapping implementation could be done either in refs.c or as presented
in this patch as a 'static inline' in the header file itself. This has the
advantage that the line of the old API is changed (and not just its
implementation in refs.c), such that it will show up in git-blame.

The new API is not perfect yet, as some of them take both a 'repository'
and 'ref_store' argument. This is done for an easy migration:
If the ref_store argument is non-NULL, prefer it over the repository
to compute which refs to iterate over. That way we can ensure that this
step of API migration doesn't confuse which ref store to work on.

Once all callers have migrated to this newly introduced API, we can
get rid of the old API; a second migration step in the future will remove
the then useless ref_store argument

Signed-off-by: Stefan Beller 
---
 refs.c | 158 +++---
 refs.h | 352 +++--
 2 files changed, 407 insertions(+), 103 deletions(-)

diff --git a/refs.c b/refs.c
index 2513f77acb3..27e3772fca9 100644
--- a/refs.c
+++ b/refs.c
@@ -217,7 +217,7 @@ char *resolve_refdup(const char *refname, int resolve_flags,
 /* The argument to filter_refs */
 struct ref_filter {
const char *pattern;
-   each_ref_fn *fn;
+   each_repo_ref_fn *fn;
void *cb_data;
 };
 
@@ -289,14 +289,15 @@ int ref_filter_match(const char *refname,
return 1;
 }
 
-static int filter_refs(const char *refname, const struct object_id *oid,
-  int flags, void *data)
+static int filter_refs(struct repository *r,
+  const char *refname, const struct object_id *oid,
+  int flags, void *data)
 {
struct ref_filter *filter = (struct ref_filter *)data;
 
if (wildmatch(filter->pattern, refname, 0))
return 0;
-   return filter->fn(refname, oid, flags, filter->cb_data);
+   return filter->fn(r, refname, oid, flags, filter->cb_data);
 }
 
 enum peel_status peel_object(const struct object_id *name, struct object_id 
*oid)
@@ -371,46 +372,50 @@ void warn_dangling_symrefs(FILE *fp, const char *msg_fmt, 
const struct string_li
for_each_rawref(warn_if_dangling_symref, );
 }
 
-int refs_for_each_tag_ref(struct ref_store *refs, each_ref_fn fn, void 
*cb_data)
+int refs_for_each_tag_repo_ref(struct repository *r, each_repo_ref_fn fn, void 
*cb_data)
 {
-   return refs_for_each_ref_in(refs, "refs/tags/", fn, cb_data);
+   return refs_for_each_repo_ref_in(r, NULL, "refs/tags/", fn, cb_data);
 }
 
-int for_each_tag_ref(each_ref_fn fn, void *cb_data)
+int for_each_tag_repo_ref(struct repository *r, each_repo_ref_fn fn, void 
*cb_data)
 {
-   return refs_for_each_tag_ref(get_main_ref_store(the_repository), fn, 
cb_data);
+   return refs_for_each_tag_repo_ref(r, fn, cb_data);
 }
 
-int refs_for_each_branch_ref(struct ref_store *refs, each_ref_fn fn, void 
*cb_data)
+int refs_for_each_branch_repo_ref(struct repository *r, struct ref_store *refs,
+ each_repo_ref_fn fn, void *cb_data)
 {
-   return refs_for_each_ref_in(refs, "refs/heads/", fn, cb_data);
+   return refs_for_each_repo_ref_in(r, refs, "refs/heads/", fn, cb_data);
 }
 
-int for_each_branch_ref(each_ref_fn fn, void *cb_data)
+int for_each_branch_repo_ref(struct repository *r, each_repo_ref_fn fn, void 
*cb_data)
 {
-   return refs_for_each_branch_ref(get_main_ref_store(the_repository), fn, 
cb_data);
+   return refs_for_each_branch_repo_ref(r, NULL, fn, cb_data);
 }
 
-int refs_for_each_remote_ref(struct ref_store *refs, each_ref_fn fn, void 
*cb_data)
+int refs_for_each_remote_repo_ref(struct repository *r, struct ref_store *refs,
+ each_repo_ref_fn fn, void *cb_data)
 {
-   return refs_for_each_ref_in(refs, "refs/remotes/", fn, cb_data);
+   return refs_for_each_repo_ref_in(r, refs, "refs/remotes/", fn, cb_data);
 }
 
-int for_each_remote_ref(each_ref_fn fn, void *cb_data)
+int for_each_remote_repo_ref(struct repository *r, each_repo_ref_fn fn, void 
*cb_data)
 {
-   return refs_for_each_remote_ref(get_main_ref_store(the_repository), fn, 
cb_data);
+   return

[PATCH 3/3] replace: migrate to for_each_replace_repo_ref

2018-07-26 Thread Stefan Beller

By upgrading the replace mechanism works well for all repositories

Signed-off-by: Stefan Beller 
---
 builtin/replace.c | 9 +
 replace-object.c  | 7 ---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/builtin/replace.c b/builtin/replace.c
index ef22d724bbc..fd8a935eb77 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -39,7 +39,8 @@ struct show_data {
enum replace_format format;
 };
 
-static int show_reference(const char *refname, const struct object_id *oid,
+static int show_reference(struct repository *r, const char *refname,
+ const struct object_id *oid,
  int flag, void *cb_data)
 {
struct show_data *data = cb_data;
@@ -56,9 +57,9 @@ static int show_reference(const char *refname, const struct 
object_id *oid,
if (get_oid(refname, ))
return error("Failed to resolve '%s' as a valid 
ref.", refname);
 
-   obj_type = oid_object_info(the_repository, ,
+   obj_type = oid_object_info(r, ,
   NULL);
-   repl_type = oid_object_info(the_repository, oid, NULL);
+   repl_type = oid_object_info(r, oid, NULL);
 
printf("%s (%s) -> %s (%s)\n", refname, 
type_name(obj_type),
   oid_to_hex(oid), type_name(repl_type));
@@ -87,7 +88,7 @@ static int list_replace_refs(const char *pattern, const char 
*format)
 "valid formats are 'short', 'medium' and 'long'\n",
 format);
 
-   for_each_replace_ref(the_repository, show_reference, (void *));
+   for_each_replace_repo_ref(the_repository, show_reference, (void 
*));
 
return 0;
 }
diff --git a/replace-object.c b/replace-object.c
index 801b5c16789..c0457b8048c 100644
--- a/replace-object.c
+++ b/replace-object.c
@@ -6,7 +6,8 @@
 #include "repository.h"
 #include "commit.h"
 
-static int register_replace_ref(const char *refname,
+static int register_replace_ref(struct repository *r,
+   const char *refname,
const struct object_id *oid,
int flag, void *cb_data)
 {
@@ -25,7 +26,7 @@ static int register_replace_ref(const char *refname,
oidcpy(_obj->replacement, oid);
 
/* Register new object */
-   if (oidmap_put(the_repository->objects->replace_map, repl_obj))
+   if (oidmap_put(r->objects->replace_map, repl_obj))
die("duplicate replace ref: %s", refname);
 
return 0;
@@ -40,7 +41,7 @@ static void prepare_replace_object(struct repository *r)
xmalloc(sizeof(*r->objects->replace_map));
oidmap_init(r->objects->replace_map, 0);
 
-   for_each_replace_ref(r, register_replace_ref, NULL);
+   for_each_replace_repo_ref(r, register_replace_ref, NULL);
 }
 
 /* We allow "recursive" replacement. Only within reason, though */
-- 
2.18.0.345.g5c9ce644c3-goog

[PATCH 1/3] refs.c: migrate internal ref iteration to pass thru repository argument

2018-07-26 Thread Stefan Beller

In 60ce76d3581 (refs: add repository argument to for_each_replace_ref,
2018-04-11) and 0d296c57aec (refs: allow for_each_replace_ref to handle
arbitrary repositories, 2018-04-11), for_each_replace_ref learned how
to iterate over refs by a given arbitrary repository.
New attempts in the object store conversion have shown that it is useful
to have the repository handle available that the refs iteration is
currently iterating over.

To achieve this goal we will need to add a repository argument to
each_ref_fn in refs.h. However as many callers rely on the signature
such a patch would be too large.

So convert the internals of the ref subsystem first to pass through a
repository argument without exposing the change to the user. Assume
the_repository for the passed through repository, although it is not
used anywhere yet.

Signed-off-by: Stefan Beller 
---
 refs.c   | 39 +--
 refs.h   | 10 ++
 refs/iterator.c  |  6 +++---
 refs/refs-internal.h |  5 +++--
 4 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/refs.c b/refs.c
index fcfd3171e83..2513f77acb3 100644
--- a/refs.c
+++ b/refs.c
@@ -1390,17 +1390,50 @@ struct ref_iterator *refs_ref_iterator_begin(
  * non-zero value, stop the iteration and return that value;
  * otherwise, return 0.
  */
+static int do_for_each_repo_ref(struct repository *r, const char *prefix,
+   each_repo_ref_fn fn, int trim, int flags,
+   void *cb_data)
+{
+   struct ref_iterator *iter;
+   struct ref_store *refs = get_main_ref_store(r);
+
+   if (!refs)
+   return 0;
+
+   iter = refs_ref_iterator_begin(refs, prefix, trim, flags);
+
+   return do_for_each_repo_ref_iterator(r, iter, fn, cb_data);
+}
+
+struct do_for_each_ref_help {
+   each_ref_fn *fn;
+   void *cb_data;
+};
+
+static int do_for_each_ref_helper(struct repository *r,
+ const char *refname,
+ const struct object_id *oid,
+ int flags,
+ void *cb_data)
+{
+   struct do_for_each_ref_help *hp = cb_data;
+
+   return hp->fn(refname, oid, flags, hp->cb_data);
+}
+
 static int do_for_each_ref(struct ref_store *refs, const char *prefix,
   each_ref_fn fn, int trim, int flags, void *cb_data)
 {
struct ref_iterator *iter;
+   struct do_for_each_ref_help hp = { fn, cb_data };
 
if (!refs)
return 0;
 
iter = refs_ref_iterator_begin(refs, prefix, trim, flags);
 
-   return do_for_each_ref_iterator(iter, fn, cb_data);
+   return do_for_each_repo_ref_iterator(the_repository, iter,
+   do_for_each_ref_helper, );
 }
 
 int refs_for_each_ref(struct ref_store *refs, each_ref_fn fn, void *cb_data)
@@ -2029,10 +2062,12 @@ int refs_verify_refname_available(struct ref_store 
*refs,
 int refs_for_each_reflog(struct ref_store *refs, each_ref_fn fn, void *cb_data)
 {
struct ref_iterator *iter;
+   struct do_for_each_ref_help hp = { fn, cb_data };
 
iter = refs->be->reflog_iterator_begin(refs);
 
-   return do_for_each_ref_iterator(iter, fn, cb_data);
+   return do_for_each_repo_ref_iterator(the_repository, iter,
+do_for_each_ref_helper, );
 }
 
 int for_each_reflog(each_ref_fn fn, void *cb_data)
diff --git a/refs.h b/refs.h
index cc2fb4c68c0..80eec8bbc68 100644
--- a/refs.h
+++ b/refs.h
@@ -274,6 +274,16 @@ struct ref_transaction;
 typedef int each_ref_fn(const char *refname,
const struct object_id *oid, int flags, void *cb_data);
 
+/*
+ * The same as each_ref_fn, but also with a repository argument that
+ * contains the repository associated with the callback.
+ */
+typedef int each_repo_ref_fn(struct repository *r,
+const char *refname,
+const struct object_id *oid,
+int flags,
+void *cb_data);
+
 /*
  * The following functions invoke the specified callback function for
  * each reference indicated.  If the function ever returns a nonzero
diff --git a/refs/iterator.c b/refs/iterator.c
index 2ac91ac3401..629e00a122a 100644
--- a/refs/iterator.c
+++ b/refs/iterator.c
@@ -407,15 +407,15 @@ struct ref_iterator *prefix_ref_iterator_begin(struct 
ref_iterator *iter0,
 
 struct ref_iterator *current_ref_iter = NULL;
 
-int do_for_each_ref_iterator(struct ref_iterator *iter,
-each_ref_fn fn, void *cb_data)
+int do_for_each_repo_ref_iterator(struct repository *r, struct ref_iterator 
*iter,
+ each_repo_ref_fn fn, void *cb_data)
 {
int retval = 0, ok;
struct ref_iterator *old_ref_iter = current_ref_iter;
 
current_ref_iter = iter;
while

Dear Friend Please Read!!!

2018-07-26 Thread Shilvock Dora

Dear Beloved,

My name is Shilvock Dora, I am 59 Years old Born and brought up in Dallas Texas,USA but I am from Canada. I have lived all my life in the USA. Last year I experienced restlessness and sleepless nights so my Doctor in New York USA sent me on a general Medical Check up at the Methodist hospital and I was finally diagnosed to have cancer of the Lungs. So my Doctor flew me back to my country Canada.

My late husbands brother wanted me dead so that he will inherit all the wealth and properties i and my late Husband suffered to build because we don't have a child. As a Christian I rather donate my money to the less privileged, orphanage homes and the Church than allow wicked people to take all when I die. Lately I discovered that my late husband??s relation know about the deposited money and they are happy that I will soon die so that they can take the money, so I will give the claim information to you before I pass on to glory.

I will give you all the details that will assist you in getting the Funds deposited with the security Company. We deposited the total of US$5,600.000.00 (Five million Six Hundred Thousand united states dollars) in cash is with the security company in USA.As soon as you accept my offer I we direct you to my family Lawyer here in New Jersey, who will assist you get the money transfer into your bank account without any delay and he will provide you with the deposit certificate to the

fund.I want to have an assurance from you that even when I die,you will not use the money wrongly and will do your best to get it from the bank in USA. I will die happily if I know you will use my funds in a manner pleasing to humanity and God when you get it.I have to rest now due to my unusual weakness. Please pray for me my dear and respond urgently to my message so that I can be able to conclude the inheritance Hand over Authorization before I die.

I anxiously await your response my dear.Please Kindly reply to my private email address: shilvocksdo...@zoho.com

Best Regards,

Shilvock Dora

Admin Help Desk.

2018-07-26 Thread Christine Lawrence

Dear User,

All staffs/students email address has been authorized for transition from 
Microsoft Outlook interface, to Google’s Gmail interface. Please 

 
Click-Here
 to Fill and Submit, in order to upgrade your email account now.

Admin Help Desk.

Re: [PATCH 1/1] add hook pre-p4-submit

2018-07-26 Thread Eric Sunshine

On Thu, Jul 26, 2018 at 12:49 PM Junio C Hamano  wrote:
> Chen Bin  writes:
> > + git p4 submit --dry-run >out && grep "Would apply" out || 
> > echo "Abort submit"
>
> What is this last "|| echo I always succeed" about?
>
> Do you want to make sure "git p4 submit" exit with non-zero exit
> status *and* its output does not say "Would apply"?  The way to
> write that would be
>
> test_must_fail git p4 submit --dry-run >out &&
> ! grep "Would apply" out

I missed the 'test_must_fail' when I suggested this same rewrite[1],
which may explain why the suggestion wasn't used in the re-roll.
Sorry.

[1]: 
https://public-inbox.org/git/capig+cr2gyewotvbmrde35rn9ovsixeerbm5ijv+fmnoibw...@mail.gmail.com/

Re: [PATCH 1/1] add hook pre-p4-submit

2018-07-26 Thread Luke Diamand

On 26 July 2018 at 10:21, Eric Sunshine  wrote:
> On Wed, Jul 25, 2018 at 10:08 PM chen bin  wrote:
>> The hook does not receive any information or input from git. The
>> original requirement
>> comes from my colleague. He want to run unit test automatically before
>> submitting code
>> to remote repository. Or else CI server will send the blame mail to the 
>> manager.
>
> Okay, that seems in line with a hook such as pre-commit. Please do
> update the documentation to mention that the hook takes no arguments
> and nothing on standard input, and perhaps describe in the
> documentation an example use-case (as you did here).
>
> I'm not a p4 or git-p4 user, but, out of curiosity, would there be any
> information which could be supplied to the hook as arguments or
> standard input (or both) which would help the hook author implement
> the hook more easily? Perhaps such information would be fodder for a
> future enhancement (not necessarily needed for this patch).

I tried to think of a use-case for a hook requiring any more
information, but I can't think of any. You're already chdir()'d to the
P4 shadow repo which is what you really need.

Anything where you just need the commit hash (e.g. checking the commit
message) can already be done with one of the existing git hooks; I
don't think git-p4 needs to duplicate that.

And we can't write a commit hook that can know about the Perforce
changelist, because we don't know what it is yet.

However, looking at the code, it runs the hook at the point just
*before* the changes are applied to the P4 shadow repo. Would it make
more sense to run the hook *after* they have been applied (but before
being P4 submitted) ?

That way you can run your tests on the checked-out P4 shadow directory
with your changes - as it stands, you can only run them on your git
repo at this point, which might not be in sync with Perforce (and
could be quite a long way out in fact).

Luke

>
>> The hook actually stops the submit process from start instead of abort
>> submit in midway.
>> So nothing is touched when hook exits with status 1.
>
> This might be a good thing to add to the documentation, as well.
>
>> I'm not sure whether `git-p4` should print some "hook rejection" message.
>> Current implementation is same as other hooks (`pre-commit`, for example).
>> Only hook itself is responsible to print error messages.
>>
>> Personally I don't have opinion whether we should print out hook
>> related message inside
>> `git-p4.py`. I just try to following existing convention of git.
>>
>> What you guys think?
>
> Following existing practice makes sense. It can always be revisited
> later if needed.
>
> Thanks.

Re: [RFC PATCH 2/5] format-patch: add --range-diff option to embed diff in cover letter

2018-07-26 Thread Eric Sunshine

On Thu, Jul 26, 2018 at 6:56 AM Johannes Schindelin
 wrote:
> On Tue, 17 Jul 2018, Eric Sunshine wrote:
> > On Tue, Jul 17, 2018 at 6:31 AM Johannes Schindelin
> >  wrote:
> > > BTW I like to have an extra space in front of all the range-diff lines, to
> > > make it easier to discern them from the rest.
> >
> > I'm not sure what you mean. Perhaps I'm misreading your comment.
>
> Sorry, I was really unclear.
>
> In the cover letters sent out by GitGitGadget (or earlier, my
> mail-patch-series.sh command), I took pains to indent the entire
> range-diff (or interdiff) with a single space. That is, the footer
> "Range-diff vs v:" is not indented at all, but all subsequent lines of
> the range-diff have a leading space.
>
> The original reason was to stop confusing `git apply` when sending an
> interdiff as part of a single patch without a cover letter (in which case
> mail-patch-series.sh inserted the interdiff below the `---` marker, and
> the interdiff would have looked like the start of the real diff
> otherwise).

The new version[1] likewise indents the interdiff to avoid confusing
git-am / git-apply.

[1]: 
https://public-inbox.org/git/20180722095717.17912-1-sunsh...@sunshineco.com/

> In the meantime, I got used to this indentation so much that I do not want
> to miss it, it is a relatively easy and intuitive visual marker.
>
> This, however, will be harder to achieve now that you are using the
> libified range-diff.

I toyed with indenting the range-diff in both the cover letter and
below the "---" line in a patch. With the libified range-diff, doing
so involves modifying the range-diff implementation (rather than
having the consumer of the range-diff manage the indentation locally),
so it adds a bit of complexity to show_range_diff(), though perhaps
not too much.

However, I opted against it for a few reasons. First, "header" lines
apart, all lines of the range-diff are already indented, and the
existing indentation was sufficient (for me, at least) as a visual
marker. Second, range-diffs tend to be _wide_, especially the header
lines, and I was loath to make it wider by indenting more. Third, due
to the existing indentation of the diff proper, a range-diff won't
confuse git-am / git-apply, nor will the unindented header lines, so
extra indentation seemed superfluous.

> > > > @@ -1438,6 +1480,7 @@ int cmd_format_patch(int argc, const char **argv, 
> > > > const char *prefix)
> > > > + const char *range_diff = NULL;
> > >
> > > Maybe `range_diff_opt`? It's not exactly the range diff that is contained
> > > in this variable.
> >
> > I could, though I was trying to keep it shorter rather than longer.
> > This is still the same in the re-roll, but I can rename it if you
> > insist.
>
> I think it will confuse me in the future if I read `range_diff` and even
> the data type suggests that it could hold the output of a `git range-diff
> ` run.
>
> So I would like to insist.

In the new version[1], this variable is named 'rdiff_prev' (the
"previous" version against which the range-diff is to be generated).

> > > > +format_patch () {
> > > > + title=$1 &&
> > > > + range=$2 &&
> > > > + test_expect_success "format-patch --range-diff ($title)" '
> > > > + git format-patch --stdout --cover-letter 
> > > > --range-diff=$range \
> > > > + master..unmodified >actual &&
> > > > + grep "= 1: .* s/5/A" actual &&
> > > > + grep "= 2: .* s/4/A" actual &&
> > > > + grep "= 3: .* s/11/B" actual &&
> > > > + grep "= 4: .* s/12/B" actual
> > >
> > > I guess this might make sense if `format_patch` was not a function, but it
> > > is specifically marked as a function... so... shouldn't these `grep`s also
> > > be using function parameters?
> >
> > A later patch adds a second test which specifies the same ranges but
> > in a different way, so the result will be the same, hence the
> > hard-coded grep'ing. The function avoids repetition across the two
> > tests. I suppose I could do this a bit differently, though, to avoid
> > pretending it's a general-purpose function.
>
> If you can think of a way that would make this easier to read for, say,
> myself if I ever find myself debugging a regression caught by this test, I
> would appreciate that.

In the new version, the function is gone; it looks like this:

--- >8 ---
for prev in topic master..topic
do
test_expect_success "format-patch --range-diff=$prev" '
git format-patch --stdout --cover-letter --range-diff=$prev \
master..unmodified >actual &&
grep "= 1: .* s/5/A" actual &&
grep "= 2: .* s/4/A" actual &&
grep "= 3: .* s/11/B" actual &&
grep "= 4: .* s/12/B" actual
'
done
--- >8 ---

Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)

2018-07-26 Thread Jeff King

On Thu, Jul 26, 2018 at 09:57:42AM -0700, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > On Wed, Jul 25, 2018 at 03:13:37PM -0700, Junio C Hamano wrote:
> >
> >> * jk/banned-function (2018-07-24) 5 commits
> >>  - banned.h: mark strncpy() as banned
> >>  - banned.h: mark sprintf() as banned
> >>  - banned.h: mark strcat() as banned
> >>  - automatically ban strcpy()
> >>  - Merge branch 'sb/blame-color' into jk/banned-function
> >> 
> >>  It is too easy to misuse system API functions such as strcat();
> >>  these selected functions are now forbidden in this codebase and
> >>  will cause a compilation failure.
> >> 
> >>  Will merge to 'next'.
> >
> > Eric nudged me over the fence to use a slightly different mechanism to
> > generate the error. See:
> >
> >   https://public-inbox.org/git/20180726072105.ga6...@sigill.intra.peff.net/
> >
> > It looks like sb/blame-color graduated, so this could also just be
> > applied directly on master now to avoid the funky merge.
> 
> OK.  Is it that "you cannot call a variable" thing?

We don't try to call it, but rather just mention it. It's just that the
compiler is more strict about undeclared variables than it is about
undeclared functions.

-Peff

Compliment of the day to you Dear Friend.

2018-07-26 Thread Mrs. Amina Kadi

 Compliment of the day to you Dear Friend.

Dear Friend.
 
  I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.

Mrs. Amina Kadi

82 matches

Mail list logo