[PATCH v3 09/34] mailinfo: do not let find_boundary() touch global "line" directly

With the previous two commits, we established that the local variable "line" in handle_body() and handle_boundary() functions always refer to the global "line" that is used as the common and shared "current line from the input". They are the only callers of the last function that refers to the

[PATCH v3 02/34] mailinfo: fold decode_header_bq() into decode_header()

In olden days we might have wanted to behave differently in decode_header() if the header line was encoded with RFC2047, but we apparently do not do so, hence this helper function can go, together with its return value. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c |

[PATCH v3 11/34] mailinfo: introduce "struct mailinfo" to hold globals

In this first step, move only 'email' and 'name' fields in there and remove the corresponding globals. In subsequent patches, more globals will be moved to this and the structure will be passed around as a new parameter to more functions. Signed-off-by: Junio C Hamano ---

[PATCH v3 10/34] mailinfo: move global "line" into mailinfo() function

With the previous steps, it becomes clear that the mailinfo() function is the only one that wants the "line" to be directly touchable. Move it to the function scope of this function. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 3 ++- 1 file changed, 2

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

Torsten Bögershausen writes: > I like this idea: > > binary > text > crlf > mixed > lf If you really like it, it would mean that my attempt to use Socratic method to enlighten you why the above is not a good idea failed X-<. > > $ git ls-files --eol-staged -s >

[PATCH v3 01/34] mailinfo: remove a no-op call convert_to_utf8(it, "")

The called function checks if the second parameter is either a NULL or an empty string at the very beginning and returns without doing anything. Remove the useless call. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 5 - 1 file changed, 5 deletions(-) diff

[PATCH v3 28/34] mailinfo: move check_header() after the helpers it uses

This way, we can lose a forward decl for decode_header(). Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 139 ++--- 1 file changed, 69 insertions(+), 70 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c

[PATCH v3 12/34] mailinfo: move keep_subject & keep_non_patch_bracket to struct mailinfo

These two are the only easy ones that do not require passing the structure around to deep corners of the callchain. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/builtin/mailinfo.c

[PATCH v3 03/34] mailinfo: fix an off-by-one error in the boundary stack

We pre-increment the pointer that we will use to store something at, so the pointer is already beyond the end of the array if it points at content[MAX_BOUNDARIES]. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v3 19/34] mailinfo: move check for metainfo_charset to convert_to_utf8()

All callers of this function refrains from calling it when mi->metainfo_charset is NULL; move the check to the callee, as it already has a few conditions at its beginning to turn it into a no-op. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 8 +++- 1 file

[PATCH v3 13/34] mailinfo: move global "FILE *fin, *fout" to struct mailinfo

This requires us to pass "struct mailinfo" to more functions throughout the codepath that read input lines. Incidentally, later steps are helped by this patch passing the struct to more callchains. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 54

[PATCH v3 16/34] mailinfo: move add_message_id and message_id to struct mailinfo

This requires us to pass the structure into check_header() codepath. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 31 +-- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index

[PATCH v3 25/34] mailinfo: handle_commit_msg() shouldn't be called after finding patchbreak

There is a strange "if (!mi->cmitmsg) return 0" at the very beginning of handle_commit_msg(), but the condition should never trigger, because: * The only place cmitmsg is set to NULL is after this function sees a patch break, closes the FILE * to write the commit log message and returns 1.

[PATCH v3 05/34] mailinfo: move handle_boundary() lower

This function wants to call find_boundary() and is called only from one place without any recursing, so it becomes easier to read if it appears after the called function. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 114

[PATCH v3 04/34] mailinfo: explicitly close file handle to the patch output

This does not make a difference within the context of "git mailinfo" that runs once and exits, as flushing and closing would happen upon process termination. It however will matter when we eventually make it callable as an API function. Besides, cleaning after yourself once you are done is a

[PATCH v3 06/34] mailinfo: get rid of function-local static states

Two helper functions use "static int" in their scope to keep track of the state while repeatedly getting called once for each input line. Move these state variables to their ultimate caller and pass down pointers to them along the callchain, as a small step in preparation for making this entire

[PATCH v3 00/34] libify mailinfo and call it directly from am

During the discussion on the recent "git am" regression, I noticed that the command reimplemented in C spawns one "mailsplit" and then spawns "mailinfo" followed by "apply --index" to commit the changes described in each message. As there are platforms where spawning subprocess via run_command()

Re: [GIT PULL] l10n updates for 2.6 maint branch

Jiang Xin writes: > Hi Junio, > > Please pull the following into the maint branch. It includes l10n > updates in Russian which missed the update window for 2.6. > > The following changes since commit 8d530c4d64ffcc853889f7b385f554d53db375ed: > > Git 2.6-rc3

Re: [PATCH] worktree: usage: denote as optional with 'add'

Sidhant Sharma writes: > Although 1eb07d8 (worktree: add: auto-vivify new branch when > is omitted, 2015-07-06) updated the documentation when > became optional, it neglected to update the in-code > usage message. Fix this oversight. > > Reported-by: ch3co...@gmail.com >

[PATCH v3 20/34] mailinfo: move transfer_encoding to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 737d0fc..18781b7 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@

[PATCH v3 29/34] mailinfo: move cleanup_space() before its users

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 6fc6aa8..104d3d9 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -41,8

[PATCH v3 18/34] mailinfo: move metainfo_charset to struct mailinfo

This requires us to pass the struct down to decode_header() and convert_to_utf8() callchain. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/builtin/mailinfo.c

[PATCH v3 21/34] mailinfo: move charset to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 18781b7..810d132 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -22,6 +22,7 @@

[PATCH v3 31/34] mailinfo: libify

Move the bulk of the code from builtin/mailinfo.c to mailinfo.c so that new callers can start calling mailinfo() directly. Note that a few calls to exit() and die() need to be cleaned up for the API to be truly useful, which will come in later steps. Signed-off-by: Junio C Hamano

[PATCH v3 32/34] mailinfo: handle charset conversion errors in the caller

Instead of dying in convert_to_utf8(), just report an error and let the callers handle it. Between the two callers: - decode_header() silently punts when it cannot parse a broken RFC2047 encoded text (e.g. when it sees anything other than B or Q after it sees "=?") by jumping to

[PATCH v3 23/34] mailinfo: move [ps]_hdr_data to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 37 +++-- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index b8b94d6..2c194da 100644 --- a/builtin/mailinfo.c +++

[PATCH v3 17/34] mailinfo: move use_scissors and use_inbody_headers to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index c0522f2..2c8f249 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -20,6

[PATCH v3 26/34] mailinfo: keep the parsed log message in a strbuf

When mailinfo() is eventually libified, the calling "git am" still will have to write out the log message in the "msg" file for hooks and other users of the information, but it does not have to reopen and reread what it wrote earlier if the function kept it in a strbuf. This also removes the need

[PATCH v3 15/34] mailinfo: move patch_lines to struct mailinfo

This one is trivial thanks to previous steps that started passing the structure throughout the input codepaths. Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/mailinfo.c

[PATCH v3 33/34] mailinfo: remove calls to exit() and die() deep in the callchain

The top-level mailinfo() would instead punt when the code in the deeper part of the callchain detects an unrecoverable error in the input. Signed-off-by: Junio C Hamano --- mailinfo.c | 30 ++ mailinfo.h | 1 + 2 files changed, 23 insertions(+), 8

[PATCH v3 22/34] mailinfo: move cmitmsg and patchfile to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 810d132..b8b94d6 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c

[PATCH v3 27/34] mailinfo: move read_one_header_line() closer to its callers

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 132 ++--- 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 81bb3c7..5a21d93 100644 --- a/builtin/mailinfo.c +++

[PATCH v3 24/34] mailinfo: move content/content_top to struct mailinfo

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 45 ++--- 1 file changed, 26 insertions(+), 19 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 2c194da..ec65805 100644 --- a/builtin/mailinfo.c +++

[PATCH v3 30/34] mailinfo: move definition of MAX_HDR_PARSED closer to its use

Signed-off-by: Junio C Hamano --- builtin/mailinfo.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c index 104d3d9..4eabc11 100644 --- a/builtin/mailinfo.c +++ b/builtin/mailinfo.c @@ -39,8 +39,6 @@ struct mailinfo

[PATCH v3 08/34] mailinfo: do not let handle_boundary() touch global "line" directly

This function has a single caller, and called with the global "line" holding the multi-part boundary line the caller saw while processing the e-mail body. The function then goes into a loop to process each line of the input, and fills the same global "line" variable from the input as it needs to

[PATCH v3 14/34] mailinfo: move filter/header stage to struct mailinfo

Earlier we got rid of two function-scope static variables that kept track of the states of helper functions by making them extra arguments that are passed throughout the callchain. Now we have a convenient place to store and pass them around in the form of "struct mailinfo", change them into two

[PATCH v3 07/34] mailinfo: do not let handle_body() touch global "line" directly

This function has a single caller, and called with the global "line" holding the first line of the e-mail body after the caller finished processing the e-mail headers. The function then goes into a loop to process each line of the input, starting from what was given by its caller, and fills the

Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options

Junio C Hamano writes: > I personally would suggest whichever order you feel more comfortable > and less error-prone. This is a good summary, and I fully agree with it. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line

Feature Request: Branch Description updating support for git fetch/pull/push

Branch descriptions are great. Even more so if you set merge.branchdesc=true (while we are at it could there be a CLI option to git merge that allowed overriding merge.branchdesc for that merge) But the bit that pains me is that my description is local only. Could we add support for syncing the

Re: [PATCH v2 3/4] stripspace: Implement --count-lines option

On 2015-10-18 at 19:18:53 +0200, Junio C Hamano wrote: > Eric Sunshine writes: > > > Is there any application beyond git-rebase--interactive where a > > --count-lines options is expected to be useful? It's not obvious from > > the commit message that

Re: [PATCH v2 3/4] stripspace: Implement --count-lines option

On 2015-10-18 at 01:57:57 +0200, Eric Sunshine wrote: > On Fri, Oct 16, 2015 at 11:16 AM, Tobias Klauser wrote: > > Implement the --count-lines options for git stripspace [...] > > > > This will make it easier to port git-rebase--interactive.sh to C

Your Inheritance

Hello, I wish to notify you that late Gianni Agnelli, had included you as beneficiary of his Will. He left the sum of sixty Million, Five Hundred Thousand Dollars (US$60, 500,000.00) to you in the Codicil and last testament to his Will. This may sound strange and unbelievable to you; you are

Re: problem with modification time of packfiles

"brian m. carlson" writes: > On Sun, Oct 18, 2015 at 10:37:55PM +0100, Andreas Amann wrote: >> git (2.6.1) sometimes updates the modification time of a packfile, even if it >> has not changed at all. >> >> On my system this triggers quite expensive an d unnecessary

Announcing Git for Windows 2.6.2

Hi all, it is my pleasure to announce that Git for Windows 2.6.2 is available. Please find it at https://git-for-windows.github.io/ Changes since Git for Windows v2.6.1 (October 5th 2015) New Features • Comes with Git v2.6.2 • Users who are part of a Windows domain now have sensible

[PATCH v1] git-p4: Add option to ignore empty commits

From: Lars Schneider A changelist that contains only excluded files (e.g. via client spec or branch prefix) will be imported as empty commit. Add option "git-p4.ignoreEmptyCommits" to ignore these commits. Signed-off-by: Lars Schneider ---

Re: [PATCH v2 3/4] stripspace: Implement --count-lines option

Eric Sunshine writes: > With this in mind, my > question was also indirectly asking whether there was sufficient > justification of the long-term cost of a --count-lines option. The > argument that --count-lines would help test a proposed > strbuf_count_lines() likely

Re: [PATCH v2 3/4] stripspace: Implement --count-lines option

On Mon, Oct 19, 2015 at 1:03 PM, Christian Couder wrote: > On Mon, Oct 19, 2015 at 3:46 PM, Tobias Klauser wrote: >> On 2015-10-18 at 19:18:53 +0200, Junio C Hamano wrote: >>> Eric Sunshine writes: >>>

Re: [PATCH] pull: add angle brackets to usage string

2015-10-16 11:42 GMT-06:00 Junio C Hamano : > Alex Henrie writes: > >> 2015-10-16 10:36 GMT-06:00 Junio C Hamano : >>> Makes sense, as all the other in the usage string are >>> bracketted. >>> >>> Does it make sense to do this for

[PATCH] fix flaky untracked-cache test

Dirty the test worktree's root directory, as the test expects. When testing the untracked-cache, we previously assumed that checking out master would be sufficient to mark the mtime of the worktree's root directory as racily-dirty. But sometimes, the checkout would happen at 12345.999 seconds

Urgent Reply

ATTN: Do you need a convenient and direct loan? We offer personal loan, car loan, small business loan and Investment financing with an affordable interest rate, fast and convenient. To apply email: enquir...@saharafc.com -- To unsubscribe from this list: send the line "unsubscribe git" in the

[PATCH 1/5] run-command: Fix early shutdown

The return value of `pp_collect_finished` indicates if we want to shutdown the parallel processing early. Both returns from that function should return any accumulated results. Signed-off-by: Stefan Beller --- run-command.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 0/5] Fixes for the parallel processing

I noticed a problem with the gracefully abortion in the parallel processing, that is fixed in patch 1. Patch 2 makes the API more maintainable/usable (the caller may forget to call child_process_init and only fill in fields which the callback is interested in) Patch 3 is another fixup. It

[RFC] URL rewrite in .gitmodules

Hi, I have a closed source Git repo which references an Open Source Git repo as Submodule. The Open Source Git repo references yet another Open Source repo as submodule. In order to avoid failing builds due to external services I mirrored the Open Source repos in my company network. That works

[PATCH 5/5] test-run-command: Increase test coverage

Signed-off-by: Stefan Beller --- t/t0061-run-command.sh | 16 +--- test-run-command.c | 12 2 files changed, 21 insertions(+), 7 deletions(-) diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh index 0af77cd..f27ada7 100755 ---

[PATCH 4/5] test-run-command: test for gracefully aborting

We reuse the get_next_task callback which would stop after invoking the test program 4 times. However as we have only 3 parallel processes started (We pass in 3 as max parallel processes and 3 is smaller than the spawn cap in run-command, so we will start the 3 processes in the first run

[PATCH 2/5] run-command: Call get_next_task with a clean child process.

If the `get_next_task` did not explicitly called child_process_init and only filled in some fields, there may have been some stale data in the child process. This is hard to debug and also adds a review burden for each new user of that API. To improve the situation, we pass only cleanly

[PATCH 3/5] run-command: Initialize the shutdown flag

It did work out without initializing the flag so far, but to make it future proof, we want to explicitly initialize the flag. Signed-off-by: Stefan Beller --- run-command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/run-command.c b/run-command.c index

Re: [RFC] URL rewrite in .gitmodules

On Mon, Oct 19, 2015 at 12:28 PM, Lars Schneider wrote: > Hi, > > I have a closed source Git repo which references an Open Source Git repo as > Submodule. The Open Source Git repo references yet another Open Source repo > as submodule. In order to avoid failing builds

Re: [PATCH v3] merge: fix cache_entry use-after-free

On Fri, 2015-10-16 at 09:04 -0700, Junio C Hamano wrote: > David Turner writes: > > > We also do dozens or hundreds of merges per day and only saw this quite > > rarely. Interestingly, we could only trigger it with an alternate > > hashing function for git's hashmap

Re: problem with modification time of packfiles

On Mon, Oct 19, 2015 at 08:59:15PM +0100, Andreas Amann wrote: > Thank you for your answer. However, this reasoning only applies to loose > objects and not packfiles. > > My understanding is that "git prune" will not prune any pack files > (except those starting with tmp_). Only "git repack"

Re: [PATCH v3 10/34] mailinfo: move global "line" into mailinfo() function

On Mon, Oct 19, 2015 at 3:28 AM, Junio C Hamano wrote: > With the previous steps, it becomes clear that the mailinfo() > function is the only one that wants the "line" to be directly > touchable. Move it to the function scope of this function. > > Signed-off-by: Junio C Hamano

Re: [PATCH v3 19/34] mailinfo: move check for metainfo_charset to convert_to_utf8()

On Mon, Oct 19, 2015 at 3:28 AM, Junio C Hamano wrote: > All callers of this function refrains from calling it when s/refrains/refrain/ > mi->metainfo_charset is NULL; move the check to the callee, > as it already has a few conditions at its beginning to turn > it into a

Re: [PATCH v4 02/26] refs: make repack_without_refs and is_branch public

On Fri, 2015-10-16 at 08:34 +0200, Michael Haggerty wrote: > On 10/15/2015 09:46 PM, David Turner wrote: > > is_branch was already non-static, but this patch declares it in the > > header. > > The commit message no longer reflects the patch. > > > Signed-off-by: Ronnie Sahlberg

Re: problem with modification time of packfiles

On Mon, Oct 19, 2015 at 11:09:19PM +, brian m. carlson wrote: > On Mon, Oct 19, 2015 at 08:59:15PM +0100, Andreas Amann wrote: > > Thank you for your answer. However, this reasoning only applies to loose > > objects and not packfiles. > > > > My understanding is that "git prune" will not

Re: [PATCH] pull: add angle brackets to usage string

Alex Henrie writes: > 2015-10-16 11:42 GMT-06:00 Junio C Hamano : >> >> Yes, but that fixes historical "mistake", no? >> >> With this, you are breaking historical practice by changing only one >> instance to deviate from the then-current practice of

Re: [PATCH v3] merge: fix cache_entry use-after-free

David Turner writes: > The problem is not the name_hash, but with the dir_hash. The dir_hash > is only even populated on case-insensitive filesystems (which is why you > and Linus don't see this bug). The dir_hash is not designed to catch > d/f conflicts, but rather

Re:My CV

Hi there! A friend of mine gave me your email adress. He was confident you would be very happy to read my CV. After looking through your homepage and seeing what it is you guys do, I am also quite sure you will not be disappointed. I'm attaching my CV for you to read. I'm truly looking forward

Re: [PATCH v2 3/4] stripspace: Implement --count-lines option

On Mon, Oct 19, 2015 at 3:46 PM, Tobias Klauser wrote: > On 2015-10-18 at 19:18:53 +0200, Junio C Hamano wrote: >> Eric Sunshine writes: >> >> > Is there any application beyond git-rebase--interactive where a >> > --count-lines

Re: [PATCH v3 10/34] mailinfo: move global "line" into mailinfo() function

Eric Sunshine writes: > On Mon, Oct 19, 2015 at 3:28 AM, Junio C Hamano wrote: >> With the previous steps, it becomes clear that the mailinfo() >> function is the only one that wants the "line" to be directly >> touchable. Move it to the function

Re: Git bug report: git doesn't change working directory

Hi Khải, On Sat, 17 Oct 2015, Khải wrote: > I'm using Windows 10. Before I install git 2.6.1.windows.1, I have > installed git 1.9.5.github.0 (by installing GitHub Desktop), it works > just fine. Good. > But when I installed git 2.6.1.windows.1 (from git-scm.com), I'm not > able to use git