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

Only the 3rd patch has changed

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

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

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

* 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):

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

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

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

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/

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

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

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

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

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

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

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

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

[PATCH 3/3] replace: migrate to for_each_replace_repo_ref

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

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

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

Dear Friend Please Read!!!

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

Admin Help Desk.

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

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

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

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

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

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

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

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

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 >

Compliment of the day to you Dear Friend.

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

Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)

Duy Nguyen writes: > I'm excited so I decided to try out anyway. This is what I've come up > with. Switching trees on git.git shows it could skip plenty entries, > so promising. It's ugly and it fails at t6020 though, there's still > work ahead. But I think it'll stop here. We are extremely

Re: [PATCH v5 1/4] add -p: select individual hunk lines

Phillip Wood writes: > +sub label_hunk_lines { > + my $hunk = shift; > + my $text = $hunk->{TEXT}; > + my (@line_flags, @lines); > + my ($block, $label, $last_mode) = (0, 0, ''); > + for my $line (1..$#{$text}) { $text is a ref to an array so @$text is the whole thing,

Re: [RFC PATCH v5 2/4] add -p: select modified lines correctly

Phillip Wood writes: An interesting problem you are solving ;-) > For example given the hunk > 1 -* a longer description of the > 2 - first item > 3 -* second > 4 -* third > 5 +* first > 6 + second item > 7 +* the third item > > If the user selects

Re: [PATCH] negotiator/skipping: skip commits during fetch

> Hi Jonathan, > > On Mon, 16 Jul 2018, Jonathan Tan wrote: > > > t/t5552-skipping-fetch-negotiator.sh | 179 +++ > > This test seems to be failing consistently in the recent `pu` builds: > > https://git-for-windows.visualstudio.com/git/_build/results?buildId=14337=logs > >

Re: [PATCH v1] checkout: optionally speed up "git checkout -b foo"

On Thu, Jul 26, 2018 at 2:59 PM Eric Sunshine wrote: > On Thu, Jul 26, 2018 at 11:04 AM Junio C Hamano wrote: > > If there were a simple and futureproof way to tell the option > > parsing loop to notice any feature other than "-b newbranch" was > > used, then such a whitelisting may be a viable

Re: [PATCH v2] name_rev: add support for --cherry-picks

Tejun Heo writes: > I should have explained the use case better. No, you did not need to. I was not saying the feature is not useful. I was only saying that "explain where in the history X sits" command (i.e. "name-rev X" and "describe X") did not look like a good place to have that feature.

Re: [PATCH v1] checkout: optionally speed up "git checkout -b foo"

On Thu, Jul 26, 2018 at 11:04 AM Junio C Hamano wrote: > Ben Peart writes: > > I'm not thrilled with the long list either (the plethora of comments > > probably makes it appear worse than it is) but I don't see how... > > If there were a simple and futureproof way to tell the option > parsing

Re: [PATCH] RFC Highlight keywords in remote sideband output.

Han-Wen Nienhuys writes: > Supported keywords are "error", "warning", "hint" and "success". > > TODO: > * make the coloring optional? What variable to use? > * doc for the coloring option. > * how to test? At the sideband layer, the sender only has the same level of information as the

Re: [PATCH v2 0/6] git-submodule.sh: convert part of cmd_update to C

> > To allow me to protest in a timely manner, I wanted to teach GitGitGadget > (which is the main reason I work on range-diff, as you undoubtedly suspect > by now) to warn me about such instances. I did not suspect that GGG is the prime motivation for range diff; as it proves useful (a) on its

Re: [PATCH] sequencer.c: terminate the last line of author-script properly

Johannes Schindelin writes: >> You're right, I'm not sure how I missed the calls to sq_quote_buf() >> yesterday, sharing the am code with the sequencer would clean things up >> nicely. > > No, actually Phillip was right. The `author-script` file written by > `git-am` was always an implementation

Re: [PATCH] RFC Highlight keywords in remote sideband output.

On Thu, Jul 26, 2018 at 10:18 AM Han-Wen Nienhuys wrote: > > Supported keywords are "error", "warning", "hint" and "success". Thanks for taking this upstream. :-) > > TODO: > * make the coloring optional? What variable to use? This is the natural extension of the topic merged at a56fb3dcc09

Re: [PATCH] sequencer.c: terminate the last line of author-script properly

Johannes Schindelin writes: > Hi Junio, > > On Tue, 17 Jul 2018, Junio C Hamano wrote: > >> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh >> index 2d189da2f1..b0cef509ab 100755 >> --- a/t/t3404-rebase-interactive.sh >> +++ b/t/t3404-rebase-interactive.sh >> @@ -81,11

Re: [PATCH v3 1/4] automatically ban strcpy()

Jeff King writes: > So here's a replacement for just patch 1 (I'm assuming this creates less > work than re-posting them all, but it may not be if Junio prefers > dealing with a whole new mbox rather than a "rebase -i", "reset --hard > HEAD^", "git am" -- let me know if you'd prefer it the other

[PATCH] RFC Highlight keywords in remote sideband output.

Supported keywords are "error", "warning", "hint" and "success". TODO: * make the coloring optional? What variable to use? * doc for the coloring option. * how to test? Signed-off-by: Han-Wen Nienhuys Change-Id: I090412a1288bc2caef0916447e28c2d0199da47d --- sideband.c | 69

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

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() >> -

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

Оля Тележная writes: > 2018-07-26 1:13 GMT+03:00 Junio C Hamano : >> >> * ot/ref-filter-object-info (2018-07-17) 5 commits >> - ref-filter: use oid_object_info() to get object >> - ref-filter: merge get_obj and get_object >> - ref-filter: initialize eaten variable >> - ref-filter: fill

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

Junio C Hamano writes: > Stefan Beller writes: > >>> * js/range-diff (2018-07-25) 21 commits > >> I think the current coloring is good enough to ship, but it still has >> errors around corners, for example introduction of new files, >> having lines in the inner diff as: >> >> diff --git

Re: [PATCH 2/2] travis-ci: fail if Coccinelle static analysis found something to transform

SZEDER Gábor writes: > On Mon, Jul 23, 2018 at 3:02 PM SZEDER Gábor wrote: > >> The only way to draw attention in such an automated setting is to fail >> the build job. Therefore, modify the 'ci/run-static-analysis.sh' >> build script to check all the resulting '*.cocci.patch' files, and >>

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

Chen Bin writes: > +Hook for submit > +~~~ > +Hook `p4-pre-submit` is executed if it exists and is executable. Just a lang nit, but "git grep pre-commit" shows me lines like Documentation/git-commit.txt: This option bypasses the pre-commit and commit-msg hooks. to tell me

Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)

On Wed, Jul 25, 2018 at 10:56 PM Ben Peart wrote: > > > > On 7/24/2018 11:33 AM, Duy Nguyen wrote: > > On Tue, Jul 24, 2018 at 6:20 AM Jeff King wrote: > >> At least that's my view of it. unpack_trees() has always been a > >> terrifying beast that I've avoided looking too closely at. > > > > /me

Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)

On Thu, Jul 26, 2018 at 07:30:20AM +0200, Duy Nguyen wrote: > Let's get back to two-way merge. I suggest you read the two-way merge > in git-read-tree.txt. That table could give you a pretty good idea > what's going on. twoway_merge() will be given a tuple of three entries > (I, H, M) of the same

[PATCH v5 3/4] add -p: allow line selection to be inverted

From: Phillip Wood If the list of lines to be selected begins with '-' select all the lines except the ones listed. Signed-off-by: Phillip Wood --- Documentation/git-add.txt | 3 ++- git-add--interactive.perl | 19 +++ t/t3701-add-interactive.sh | 2 +- 3 files changed, 22

[PATCH v5 1/4] add -p: select individual hunk lines

From: Phillip Wood When I end up editing hunks it is almost always because I want to stage a subset of the lines in the hunk. Doing this by editing the hunk is inconvenient and error prone (especially so if the patch is going to be reversed before being applied). Instead offer an option for add

[PATCH v5 4/4] add -p: optimize line selection for short hunks

From: Phillip Wood If there are fewer than ten changes in a hunk then make spaces optional when selecting individual lines. This means that for short hunks one can just type 1-357 to stage lines 1, 2, 3, 5 & 7. Signed-off-by: Phillip Wood --- Documentation/git-add.txt | 9 +

[RFC PATCH v5 2/4] add -p: select modified lines correctly

From: Phillip Wood When a set of lines is modified the hunk contains deletions followed by insertions. To correctly stage a subset of the modified lines we need to match up the selected deletions with the selected insertions otherwise we end up with deletions and context lines followed by

[RFC PATCH v5 0/4] add -p: select individual hunk lines

From: Phillip Wood Unfortuantely v4 had test failures due to a suprious brace from a last minute edit to a comment that I forgot to test. This version fixes that, my applogies for the patch churn. I've updated this series based on Ævar's feedback on v3 (to paraphrase stop using '$_' so much and

Re: [RFC PATCH 0/5] format-patch: automate cover letter range-diff

Hi Andrei, On Thu, 26 Jul 2018, Andrei Rybak wrote: > On 2018-05-30 10:03, Eric Sunshine wrote: > > Dscho recently implemented a 'tbdiff' replacement as a Git builtin named > > git-branch-diff[1] which computes differences between two versions of a > > patch series. Such a diff can be a useful

Re: [PATCH v2] name_rev: add support for --cherry-picks

Hello, Junio. On Thu, Jul 26, 2018 at 08:12:45AM -0700, Junio C Hamano wrote: > Tejun Heo writes: > > > From a6a88c3da252d69547ac8b463098fc4f4c03f322 Mon Sep 17 00:00:00 2001 > > From: Tejun Heo > > Date: Thu, 26 Jul 2018 04:14:52 -0700 > > Subject: [PATCH] name_rev: add support for

Re: [PATCH v2] name_rev: add support for --cherry-picks

Tejun Heo writes: > From a6a88c3da252d69547ac8b463098fc4f4c03f322 Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Thu, 26 Jul 2018 04:14:52 -0700 > Subject: [PATCH] name_rev: add support for --cherry-picks The above belongs to the mail header, not the body. > It's often useful to track

Re: [PATCH v1] checkout: optionally speed up "git checkout -b foo"

Ben Peart writes: [jc: it was a bit surprising that Eric covered all the bits I covered while we were writing without peeking each other's ;-)] >> This long list of special-case checks doesn't leave me too enthused, >> however, that aside, this approach seems backward. Rather than erring >> on

[PATCH v2] name_rev: add support for --cherry-picks

>From a6a88c3da252d69547ac8b463098fc4f4c03f322 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Thu, 26 Jul 2018 04:14:52 -0700 Subject: [PATCH] name_rev: add support for --cherry-picks It's often useful to track cherry-picks of a given commit. Add --cherry-picks support to git-name-rev. When

Re: [PATCH] negotiator/skipping: skip commits during fetch

Hi Jonathan, On Thu, 26 Jul 2018, Johannes Schindelin wrote: > On Mon, 16 Jul 2018, Jonathan Tan wrote: > > > t/t5552-skipping-fetch-negotiator.sh | 179 +++ > > This test seems to be failing consistently in the recent `pu` builds: > >

[PATCH v2 2/2] doc hash-function-transition: pick SHA-256 as NewHash

>From a security perspective, it seems that SHA-256, BLAKE2, SHA3-256, K12, and so on are all believed to have similar security properties. All are good options from a security point of view. SHA-256 has a number of advantages: * It has been around for a while, is widely used, and is supported

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

Hook pre-p4-submit is executed before git-p4 actually submits code. If the hook exits with non-zero value, submit process will abort. Signed-off-by: Chen Bin --- Documentation/git-p4.txt | 12 Documentation/githooks.txt | 7 +++ git-p4.py | 21

Re: [RFC PATCH 0/5] Add delta islands support

Hi Chris, On Sun, 22 Jul 2018, Christian Couder wrote: > This patch series is upstreaming work made by GitHub and available in: > > https://github.com/peff/git/commits/jk/delta-islands > > The patch in the above branch has been split into 5 patches with their > own new commit message, but no

Re: [PATCH] sequencer.c: terminate the last line of author-script properly

Hi Phillip, On Thu, 19 Jul 2018, Phillip Wood wrote: > On 18/07/18 18:17, Junio C Hamano wrote: > > Phillip Wood writes: > > > >>> (I think we had code to do so in "git am" > >>> that was rewritten in C first). > >> > >> The code in builtin/am.c doesn't try to write valid posix shell (if > >>

Re: [RFC PATCH] sequencer: fix quoting in write_author_script

Hi Phillip, On Wed, 18 Jul 2018, Phillip Wood wrote: > From: Phillip Wood > > Single quotes should be escaped as \' not \\'. Note that this only > affects authors that contain a single quote and then only external > scripts that read the author script and users whose git is upgraded from > the

[PATCH] name_rev: add support for --cherry-picks

>From aefa07bc66bb4a116eb84eb46d7f070f9632c990 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Thu, 26 Jul 2018 04:14:52 -0700 It's often useful to track cherry-picks of a given commit. Add --cherry-picks support to git-name-rev. When specified, name_rev also shows the commits cherry-picked

fatal: could not read '': No such file or directory

While committing a repo I get the error "fatal: could not read '': No such file or directory”. The git repo is a samba share mounted with smb vers=1.0 in linux using cifs-utils. I tried git rm —cached ./* && git add —all && git commit -a -m “commit msg” It gives the error. I suppose it's a

Re: [PATCH] sequencer.c: terminate the last line of author-script properly

Hi Junio, On Tue, 17 Jul 2018, Junio C Hamano wrote: > diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh > index 2d189da2f1..b0cef509ab 100755 > --- a/t/t3404-rebase-interactive.sh > +++ b/t/t3404-rebase-interactive.sh > @@ -81,11 +81,13 @@ test_expect_success 'rebase -i

Re: [RFC PATCH 0/5] format-patch: automate cover letter range-diff

On 2018-05-30 10:03, Eric Sunshine wrote: > Dscho recently implemented a 'tbdiff' replacement as a Git builtin named > git-branch-diff[1] which computes differences between two versions of a > patch series. Such a diff can be a useful aid for reviewers when > inserted into a cover letter. However,

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

Hi Eric, On Tue, 17 Jul 2018, Eric Sunshine wrote: > On Tue, Jul 17, 2018 at 6:31 AM Johannes Schindelin > wrote: > > On Wed, 30 May 2018, Eric Sunshine wrote: > > > > + if (range_diff) { > > > + struct argv_array ranges = ARGV_ARRAY_INIT; > > > +

Re: [PATCH v2 0/6] git-submodule.sh: convert part of cmd_update to C

Hi Stefan, On Tue, 17 Jul 2018, Stefan Beller wrote: > > A tangent. > > > > Because this "-- " is a conventional signature separator, MUAs like > > Emacs message-mode seems to omit everything below it from the quote > > while responding, making it cumbersome to comment on the tbdiff. > > > >

Re: [PATCH] negotiator/skipping: skip commits during fetch

Hi Jonathan, On Mon, 16 Jul 2018, Jonathan Tan wrote: > t/t5552-skipping-fetch-negotiator.sh | 179 +++ This test seems to be failing consistently in the recent `pu` builds: https://git-for-windows.visualstudio.com/git/_build/results?buildId=14337=logs Could you have a look,

Re: Hash algorithm analysis

Hi Joan, On Sun, 22 Jul 2018, Joan Daemen wrote: > I wanted to react to some statements I read in this discussion. But > first let me introduce myself. I'm Joan Daemen and I'm working in > symmetric cryptography since 1988. Vincent Rijmen and I designed > Rijndael that was selected to become AES

photos for your company

I would like to contact the person that manages your images for your company? We provide different services that makes your images and pictures to look good. For the images to be more attractive, we services such as background image cut out, clipping path, shadow adding (drop shadow, reflection

[RFC PATCH v4 0/4] add -p: select individual hunk lines

From: Phillip Wood I've updated this series based on Ævar's feedback on v3 (to paraphrase stop using '$_' so much and fix staging modified lines.). The first patch is functionally equivalent to the previous version but with a reworked implementation. Patch 2 is new, it implements correctly

[PATCH v4 4/4] add -p: optimize line selection for short hunks

From: Phillip Wood If there are fewer than ten changes in a hunk then make spaces optional when selecting individual lines. This means that for short hunks one can just type 1-357 to stage lines 1, 2, 3, 5 & 7. Signed-off-by: Phillip Wood --- Documentation/git-add.txt | 9 +

[PATCH v4 1/4] add -p: select individual hunk lines

From: Phillip Wood When I end up editing hunks it is almost always because I want to stage a subset of the lines in the hunk. Doing this by editing the hunk is inconvenient and error prone (especially so if the patch is going to be reversed before being applied). Instead offer an option for add

[RFC PATCH v4 2/4] add -p: select modified lines correctly

From: Phillip Wood When a set of lines is modified the hunk contains deletions followed by insertions. To correctly stage a subset of the modified lines we need to match up the selected deletions with the selected insertions otherwise we end up with deletions and context lines followed by

[PATCH v4 3/4] add -p: allow line selection to be inverted

From: Phillip Wood If the list of lines to be selected begins with '-' select all the lines except the ones listed. Signed-off-by: Phillip Wood --- Documentation/git-add.txt | 3 ++- git-add--interactive.perl | 19 +++ t/t3701-add-interactive.sh | 2 +- 3 files changed, 22

Re: Hash algorithm analysis

Hi Eric, On Sun, 22 Jul 2018, Eric Deplagne wrote: > On Sun, 22 Jul 2018 14:21:48 +, brian m. carlson wrote: > > On Sun, Jul 22, 2018 at 11:34:42AM +0200, Eric Deplagne wrote: > > > On Sat, 21 Jul 2018 23:59:41 +, brian m. carlson wrote: > > > > I don't know your colleagues, and they

Re: [PATCH v4 00/21] Add `range-diff`, a `tbdiff` lookalike

Hi Stefan, On Mon, 23 Jul 2018, Stefan Beller wrote: > On Sat, Jul 21, 2018 at 3:04 PM Johannes Schindelin via GitGitGadget > wrote: > > > Range-diff vs v3: > > > > 1: 39272eefc ! 1: f7e70689e linear-assignment: a function to solve > > least-cost assignment problems > > @@ -223,9

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

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

Re: [PATCH v1 03/25] structured-logging: add structured logging framework

> +void slog_set_command_name(const char *command_name) > +{ > + /* > + * Capture the command name even if logging is not enabled > + * because we don't know if the config has been loaded yet by > + * the cmd_() and/or it may be too early to force a > + * lazy load. > +

Re: [PATCH 2/2] travis-ci: fail if Coccinelle static analysis found something to transform

On Mon, Jul 23, 2018 at 3:02 PM SZEDER Gábor wrote: > The only way to draw attention in such an automated setting is to fail > the build job. Therefore, modify the 'ci/run-static-analysis.sh' > build script to check all the resulting '*.cocci.patch' files, and > fail the build job if any of

Re: Git Help !!!

Awesome, thanks! On Thu, 26 Jul 2018, 2:00 p.m. Eric Sunshine, wrote: > On Thu, Jul 26, 2018 at 1:01 AM Vishwas Kamath > wrote: > > I am unable to use Git (version 2.18 latest). Since i couldnt find any > help/support/contact email on https://git-scm.com and i couldnt find the > solution using

Re: Git Help !!!

On Thu, Jul 26, 2018 at 1:01 AM Vishwas Kamath wrote: > I am unable to use Git (version 2.18 latest). Since i couldnt find any > help/support/contact email on https://git-scm.com and i couldnt find the > solution using Google as well i am directly contacting you as i need to get > git working.

Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas

Am 22.07.2018 um 10:04 schrieb Nguyễn Thái Ngọc Duy: + if (size < pack->oe_delta_size_limit) { + e->delta_size_ = size; + e->delta_size_valid = 1; + } else { + packing_data_lock(pack); + if (!pack->delta_size) +

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

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'

[PATCH v3 1/4] automatically ban strcpy()

On Thu, Jul 26, 2018 at 02:58:40AM -0400, Jeff King wrote: > On Tue, Jul 24, 2018 at 01:20:58PM -0400, Eric Sunshine wrote: > > > On Tue, Jul 24, 2018 at 5:26 AM Jeff King wrote: > > > 1. We'll only trigger with -Wimplicit-function-declaration > > > (and only stop compilation with

Re: [PATCH v2 1/4] automatically ban strcpy()

On Tue, Jul 24, 2018 at 01:20:58PM -0400, Eric Sunshine wrote: > On Tue, Jul 24, 2018 at 5:26 AM Jeff King wrote: > > 1. We'll only trigger with -Wimplicit-function-declaration > > (and only stop compilation with -Werror). These are > > generally enabled by DEVELOPER=1. If you

Re: [PATCH 5/6] pass st.st_size as hint for strbuf_readlink()

On Wed, Jul 25, 2018 at 08:41:00PM +0200, Torsten Bögershausen wrote: > On Tue, Jul 24, 2018 at 06:51:39AM -0400, Jeff King wrote: > > When we initially added the strbuf_readlink() function in > > b11b7e13f4 (Add generic 'strbuf_readlink()' helper function, > > 2008-12-17), the point was that we

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

2018-07-26 1:13 GMT+03:00 Junio C Hamano : > > * ot/ref-filter-object-info (2018-07-17) 5 commits > - ref-filter: use oid_object_info() to get object > - ref-filter: merge get_obj and get_object > - ref-filter: initialize eaten variable > - ref-filter: fill empty fields with empty values > -