Why Me In This Terrible Condition.

Greetings My Dear, I sent this mail praying it will found you in a good condition of health, since I myself are in a very critical health condition in which I sleep every night without knowing if I may be alive to see the next day. I am Mrs. Francisca Carlsen from Denmark wife of late Mr

HELLO

Did you get my previous Email??

[PATCH v6 1/1] http: add support selecting http version

From: Force Charlie Usually we don't need to set libcurl to choose which version of the HTTP protocol to use to communicate with a server. But different versions of libcurl, the default value is not the same. CURL >= 7.62.0: CURL_HTTP_VERSION_2TLS CURL < 7.62: CURL_HTTP_VERSION_1_1 In order to

[PATCH v6 0/1] http: add support selecting http version

Usually we don't need to set libcurl to choose which version of the HTTP protocol to use to communicate with a server. But different versions of libcurl, the default value is not the same. CURL >= 7.62.0: CURL_HTTP_VERSION_2TLS CURL < 7.62: CURL_HTTP_VERSION_1_1 In order to give users the

Re: [PATCH v2 0/2] Reimplement rebase --merge via interactive machinery

On Wed, Nov 7, 2018 at 10:02 PM Elijah Newren wrote: > > Now that the rewrite-interactive-rebases-in-C series have finally > merged to master, this series deletes git-rebase--merge.sh and > reimplements the --merge behavior on top of the interactive machinery. > > Differences since v1: > -

[PATCH v5 0/1] http: add support selecting http version

Normally, git doesn't need to set curl to select the HTTP version, it works fine without HTTP/2. Adding HTTP/2 support is a icing on the cake. This patch support force enable HTTP/2 or HTTP/1.1. example: GIT_CURL_VERBOSE=1 git2 -c http.version=HTTP/2 ls-remote

[PATCH v5 1/1] http: add support selecting http version

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/http.c b/http.c index 3dc8c560d6..d6f3c4ee80 100644 --- a/http.c +++ b/http.c @@ -48,6 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static

[PATCH v4 2/4] support force use http 1.1

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/http.c b/http.c index 99cb04faba..b2ec31aef5 100644 --- a/http.c +++ b/http.c @@ -48,7 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int

Re: [PATCH v3 0/4] http: add support selecting http version

"Force.Charlie-I via GitGitGadget" writes: > Normally, git doesn't need to set curl to select the HTTP version, it works > fine without HTTP/2. Adding HTTP/2 support is a icing on the cake. > > This patch support force enable HTTP/2 or HTTP/1.1. > > example: > > GIT_CURL_VERBOSE=1 git2 -c

[PATCH v4 0/4] http: add support selecting http version

Normally, git doesn't need to set curl to select the HTTP version, it works fine without HTTP/2. Adding HTTP/2 support is a icing on the cake. This patch support force enable HTTP/2 or HTTP/1.1. example: GIT_CURL_VERBOSE=1 git2 -c http.version=HTTP/2 ls-remote

[PATCH v4 4/4] http: change http.version value type

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 41 - 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/http.c b/http.c index 86e454cff5..d6f3c4ee80 100644 --- a/http.c +++ b/http.c @@ -48,7 +48,7 @@ char

[PATCH v4 3/4] fix curl version to support CURL_HTTP_VERSION_2TLS

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/http.c b/http.c index b2ec31aef5..86e454cff5 100644 --- a/http.c +++ b/http.c @@ -811,10 +811,10 @@ static CURL *get_curl_handle(void)

[PATCH v4 1/4] http: add support selecting http version

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 12 1 file changed, 12 insertions(+) diff --git a/http.c b/http.c index 3dc8c560d6..99cb04faba 100644 --- a/http.c +++ b/http.c @@ -48,6 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int curl_ssl_verify = -1;

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

Junio C Hamano writes: >> Not surprising. The i18n series makes fsck output localized strings >> and without updating grep to test_i18ngrep, new tests will fail. If >> 'pu' was passing before, I'm ok with just ejecting this series for >> now. Then I wait for the other to land, rebase, fixup and

[PATCH v2 0/2] Reimplement rebase --merge via interactive machinery

Now that the rewrite-interactive-rebases-in-C series have finally merged to master, this series deletes git-rebase--merge.sh and reimplements the --merge behavior on top of the interactive machinery. Differences since v1: - Updated code to hook into builtin/rebase.C instead of git-rebase.sh

[PATCH v2 2/2] rebase: Implement --merge via git-rebase--interactive

Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having

[PATCH v2 1/2] git-rebase, sequencer: extend --quiet option for the interactive machinery

While 'quiet' and 'interactive' may sound like antonyms, the interactive machinery actually has logic that implements several interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges) which won't pop up an editor. The rewrite of interactive rebase in C added a quiet option, though

Re: [PATCH v5 10/10] merge-recursive: combine error handling

Elijah Newren writes: > From: Derrick Stolee > > In handle_rename_rename_1to2(), we have duplicated error handling > around colliding paths. Specifically, when we want to write out > the file and there is a directory or untracked file in the way, > we need to create a temporary file to hold the

how does "clone --filter=sparse:path" work?

[cc-ing people who worked on or seem interested in partial-clone filters] I've been exploring the partial-clone options a bit, and took a look at the "sparse:path" option. I had some confusion initially, because I expected it work something like this: git clone

[PATCH v3 4/4] http: change http.version value type

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/http.c b/http.c index 86e454cff5..0ad797caea 100644 --- a/http.c +++ b/http.c @@ -48,7 +48,7 @@ char

[PATCH v3 0/4] http: add support selecting http version

Normally, git doesn't need to set curl to select the HTTP version, it works fine without HTTP/2. Adding HTTP/2 support is a icing on the cake. This patch support force enable HTTP/2 or HTTP/1.1. example: GIT_CURL_VERBOSE=1 git2 -c http.version=HTTP/2 ls-remote

[PATCH v3 1/4] http: add support selecting http version

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 12 1 file changed, 12 insertions(+) diff --git a/http.c b/http.c index 3dc8c560d6..99cb04faba 100644 --- a/http.c +++ b/http.c @@ -48,6 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int curl_ssl_verify = -1;

[PATCH v3 2/4] support force use http 1.1

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/http.c b/http.c index 99cb04faba..b2ec31aef5 100644 --- a/http.c +++ b/http.c @@ -48,7 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int

[PATCH v3 3/4] fix curl version to support CURL_HTTP_VERSION_2TLS

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/http.c b/http.c index b2ec31aef5..86e454cff5 100644 --- a/http.c +++ b/http.c @@ -811,10 +811,10 @@ static CURL *get_curl_handle(void)

[PATCH v5 08/10] merge-recursive: improve rename/rename(1to2)/add[/add] handling

When we have a rename/rename(1to2) conflict, each of the renames can collide with a file addition. Each of these rename/add conflicts suffered from the same kinds of problems that normal rename/add suffered from. Make the code use handle_file_conflicts() as well so that we get all the same fixes

[PATCH v5 01/10] Add testcases for consistency in file collision conflict handling

Add testcases dealing with file collisions for the following types of conflicts: * add/add * rename/add * rename/rename(2to1) All these conflict types simplify down to two files "colliding" and should thus be handled similarly. This means that rename/add and rename/rename(2to1) conflicts

[PATCH v5 10/10] merge-recursive: combine error handling

From: Derrick Stolee In handle_rename_rename_1to2(), we have duplicated error handling around colliding paths. Specifically, when we want to write out the file and there is a directory or untracked file in the way, we need to create a temporary file to hold the contents. This has some special

[PATCH v5 02/10] t6036, t6042: testcases for rename collision of already conflicting files

When a single file is renamed, it can also be modified, yielding the possibility of that renamed file having content conflicts. If two different such files are renamed into the same location, then two-way merging those files may result in nested conflicts. Add a testcase that makes sure we get

[PATCH v5 05/10] merge-recursive: fix rename/add conflict handling

This makes the rename/add conflict handling make use of the new handle_file_collision() function, which fixes several bugs and improves things for the rename/add case significantly. Previously, rename/add would: * Not leave any higher order stage entries in the index, making it appear as

[PATCH v5 03/10] merge-recursive: increase marker length with depth of recursion

Later patches in this series will modify file collision conflict handling (e.g. from rename/add and rename/rename(2to1) conflicts) so that multiply nested conflict markers can arise even before considering conflicts in the virtual merge base. Including the virtual merge base will provide a way to

[PATCH v5 04/10] merge-recursive: new function for better colliding conflict resolutions

There are three conflict types that represent two (possibly entirely unrelated) files colliding at the same location: * add/add * rename/add * rename/rename(2to1) These three conflict types already share more similarity than might be immediately apparent from their description: (1) the

[PATCH v5 06/10] merge-recursive: improve handling for rename/rename(2to1) conflicts

This makes the rename/rename(2to1) conflicts use the new handle_file_collision() function. Since that function was based originally on the rename/rename(2to1) handling code, the main differences here are in what was added. In particular: * Instead of storing files at collide_path~HEAD and

[PATCH v5 09/10] t6036, t6043: increase code coverage for file collision handling

Stolee's coverage reports found a few code blocks for file collision conflicts that had not previously been covered by testcases; add a few more testcases to cover those too. Signed-off-by: Elijah Newren --- t/t6036-recursive-corner-cases.sh | 51 +

[PATCH v5 07/10] merge-recursive: use handle_file_collision for add/add conflicts

This results in no-net change of behavior, it simply ensures that all file-collision conflict handling types are being handled the same by calling the same function. Signed-off-by: Elijah Newren --- merge-recursive.c | 29 + 1 file changed, 21 insertions(+), 8

[PATCH v5 00/10] Improve path collision conflict resolutions

This series applies cleanly on master, since en/merge-cleanup-more has now merged down. This series makes all the "file collision" conflict types be handled consistently; making them all behave like add/add (as suggested by Jonathan[1] and Junio[2]). These types are: * add/add * rename/add

Re: [PATCH] branch: make --show-current use already resolved HEAD

I did something that resulted in the mailing list not being cc'd. Apologies to Junio and Daniels for the double send. :( On Thu, Nov 08, 2018 at 10:11:02AM +0900, Junio C Hamano wrote: > I'd prefer to see scriptors avoid using "git branch", too. > > Unlike end-user facing documentation where we

Re: [PATCH 0/1] http: add support selecting http version

"brian m. carlson" writes: > On Wed, Nov 07, 2018 at 02:44:51PM +0100, Daniel Stenberg wrote: >> On Wed, 7 Nov 2018, Force.Charlie-I via GitGitGadget wrote: >> >> > Normally, git doesn't need to set curl to select the HTTP version, it >> > works fine without HTTP2. Adding HTTP2 support is a

Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

Jeff King writes: > So if we are comfortable with saying that this is a new feature to have > the machine-readable trailer version, and there isn't a robust way to > get historical revert information (because there really isn't[1]), then > I think we can just punt on any kind of

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Jeff King writes: > I think we would want to carefully think about the call in enter_repo(). > We do not want git-daemon to accidentally expose repositories in > $RUNTIME_PREFIX. > > Looking over the code, I think this is OK. The expansion happens in > enter_repo(), and then we take the path

Re: [PATCH v3] i18n: make GETTEXT_POISON a runtime option

Ævar Arnfjörð Bjarmason writes: > * We error out in the Makefile if you're still saying >GETTEXT_POISON=YesPlease. I expected this would be irritating, but it turns out it is worse than mere irritation but is a severe hinderance to affect my performance, as I (and my bots) keep building

Re: [PATCH 1/1] http: add support selecting http version

"Force Charlie via GitGitGadget" writes: > From: Force Charlie > > Signed-off-by: Force Charlie > --- > http.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/http.c b/http.c > index 3dc8c560d6..99cb04faba 100644 > --- a/http.c > +++ b/http.c > @@ -48,6 +48,7 @@ char

[PATCH v2 3/3] fix curl version to support CURL_HTTP_VERSION_2TLS

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/http.c b/http.c index b2ec31aef5..86e454cff5 100644 --- a/http.c +++ b/http.c @@ -811,10 +811,10 @@ static CURL *get_curl_handle(void)

[PATCH v2 0/3] http: add support selecting http version

Normally, git doesn't need to set curl to select the HTTP version, it works fine without HTTP2. Adding HTTP2 support is a icing on the cake. When http.version=20 is set, git will attempt to request the server using HTTP2. If the remote server does not support HTTP2, it is no different. Currently

[PATCH v2 1/3] http: add support selecting http version

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 12 1 file changed, 12 insertions(+) diff --git a/http.c b/http.c index 3dc8c560d6..99cb04faba 100644 --- a/http.c +++ b/http.c @@ -48,6 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int curl_ssl_verify = -1;

[PATCH v2 2/3] support force use http 1.1

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/http.c b/http.c index 99cb04faba..b2ec31aef5 100644 --- a/http.c +++ b/http.c @@ -48,7 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int

Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

On Thu, Nov 08, 2018 at 09:36:56AM +0900, Junio C Hamano wrote: > Duy Nguyen writes: > > > There is still one thing to settle. "revert -m1" could produce > > something like this > > > > This reverts commit , reversing > > changes made to . > > I do not think it is relevant, with or

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Thu, Nov 08, 2018 at 09:30:15AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Nov 07, 2018 at 10:36:52PM +0100, Johannes Sixt wrote: > > > > All that said, if we're just interested in allowing this for config, > > then we already have such a wrapper function:

Re: [PATCH 0/1] http: add support selecting http version

On Wed, Nov 07, 2018 at 02:44:51PM +0100, Daniel Stenberg wrote: > On Wed, 7 Nov 2018, Force.Charlie-I via GitGitGadget wrote: > > > Normally, git doesn't need to set curl to select the HTTP version, it > > works fine without HTTP2. Adding HTTP2 support is a icing on the cake. > > Just a FYI: >

Re: [PATCH] branch: make --show-current use already resolved HEAD

Rafael Ascensão writes: > print_current_branch_name() tries to resolve HEAD and die() when it > doesn't resolve it successfully. But the conditions being tested are > always unreachable because early in branch:cmd_branch() the same logic > is performed. > > Eliminate the duplicate and

Re: [RFC PATCH 3/3] list-objects-filter: teach tree:# how to handle >0

A quick update: I've read Junio's comments on this patchset and basically agree with them, but I haven't had a chance to apply them yet. I plan to pick this patchset up again (as well as the patch "md/list-lazy-objects-fix") once things settle down in my day job. On Sun, Oct 14, 2018 at 7:31 PM

Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

Duy Nguyen writes: > There is still one thing to settle. "revert -m1" could produce > something like this > > This reverts commit , reversing > changes made to . I do not think it is relevant, with or without multiple parents, to even attempt to read this message. The description is

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Jeff King writes: > On Wed, Nov 07, 2018 at 10:36:52PM +0100, Johannes Sixt wrote: > > All that said, if we're just interested in allowing this for config, > then we already have such a wrapper function: git_config_pathname(). > > So I don't think it's a big deal to implement it in any of these

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Ramsay Jones writes: >> The cute thing is: your absolute paths would not be moved because we are >> talking about Windows. Therefore your absolute paths would not start with >> a forward slash. > > Ah, sorry, I must have misunderstood a comment in your cover letter: > > The reason is this:

Re: What exactly is a "initial checkout"

On 07/11/2018 08:50, Christian Halstrick wrote: Ok, I know understand the problems which are solved by this special behaviour of a "initial checkout". And also important I understand when exactly I should do a "initial checkout" - when the index file does not exist. I'll share my new knowledge

[PATCH] branch: make --show-current use already resolved HEAD

print_current_branch_name() tries to resolve HEAD and die() when it doesn't resolve it successfully. But the conditions being tested are always unreachable because early in branch:cmd_branch() the same logic is performed. Eliminate the duplicate and unreachable code, and update the current logic

Re: [RFC PATCH] index-pack: improve performance on NFS

On Mon, Oct 29, 2018 at 07:27:39PM -0400, Jeff King wrote: > On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð Bjarmason wrote: > > * Re-roll my 4 patch series to include the patch you have in > ><20181027093300.ga23...@sigill.intra.peff.net> > > I don't think it's quite ready for

Re: [PATCH v3 1/2] range-diff doc: add a section about output stability

Stephen & Linda Smith writes: >> +This is particularly true when passing in diff options. Currently some >> +options like `--stat` can as an emergent effect produce output that's > > "`--stat` can as an emergent": I read that for times to decided it was > correct > grammar. Should it be

Re: [PATCH v2] format-patch: respect --stat in cover letter's diffstat

On 11/07/18 17:49, Nguyễn Thái Ngọc Duy wrote: > Commit 43662b23ab (format-patch: keep cover-letter diffstat wrapped in > 72 columns - 2018-01-24) uncondtionally sets stat width to 72 when > generating diffstat for the cover letter, ignoring --stat from command > line. But it should only do so

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

Duy Nguyen writes: > On Wed, Nov 7, 2018 at 2:09 PM SZEDER Gábor wrote: >> >> On Wed, Nov 07, 2018 at 06:41:45PM +0900, Junio C Hamano wrote: >> > * nd/i18n (2018-11-06) 16 commits >> > - fsck: mark strings for translation >> > - fsck: reduce word legos to help i18n >> > ... >> > More

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Wed, Nov 07, 2018 at 10:36:52PM +0100, Johannes Sixt wrote: > Am 07.11.18 um 21:41 schrieb Jeff King: > > On Wed, Nov 07, 2018 at 07:52:28PM +0100, Johannes Sixt wrote: > > > Do I understand correctly, that you use a leading slash as an indicator to > > > construct a path relative to

You emailed AcroArts Productions

Name: you開﹤普.专。票﹥，电/微：134//186//l8⑼//58，长=期=有=效 Email: git@vger.kernel.org Comments: you開﹤普.专。票﹥，电/微：134//186//l8⑼//58，长=期=有=效

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Am 07.11.18 um 21:41 schrieb Jeff King: On Wed, Nov 07, 2018 at 07:52:28PM +0100, Johannes Sixt wrote: Do I understand correctly, that you use a leading slash as an indicator to construct a path relative to system_path(). How about a "reserved" user name? For example, [http] sslcert =

Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

On Wed, Nov 07, 2018 at 04:30:38PM +0100, Duy Nguyen wrote: > > Could we help the reading scripts by normalizing old and new output via > > interpret-trailers, %(trailers), etc? > > > > I think "(cherry picked from ...)" is already considered a trailer by > > the trailer code. If the caller

Re: [PATCH 2/2] built-in rebase --autostash: leave the current branch alone if possible

On Wed, Nov 07, 2018 at 06:00:50AM -0800, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > When we converted a `git reset --hard` call in the original Unix shell > script to built-in code, we asked to reset the worktree and the index > and explicitly *not* to detach

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On Wed, Nov 07, 2018 at 07:52:28PM +0100, Johannes Sixt wrote: > > Okay, now we know everything you find wrong with the current patch. Do you > > have any suggestion how to make it right? I.e. what would you suggest as a > > way to specify in a gitconfig in a portable Git where the certificate >

Attention.

Compliments of the day ; I have a business proposition for you which I sent you previously,I do not know if you received it? Please do find it proper to write me if your email is still active. Yours Faithfully, Barr. Alexander Stewart.

Re: [PATCH v3 1/2] range-diff doc: add a section about output stability

On Wed, 7 Nov 2018 at 13:22, Ævar Arnfjörð Bjarmason wrote: > + > +This is particularly true when passing in diff options. Currently some > +options like `--stat` can as an emergent effect produce output that's > +quite useless in the context of `range-diff`. Future versions of > +`range-diff`

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Am 07.11.18 um 12:23 schrieb Johannes Schindelin: On Tue, 6 Nov 2018, Johannes Sixt wrote: Am 06.11.18 um 15:53 schrieb Johannes Schindelin via GitGitGadget: Even if a path looks like a POSIX paths, i.e. it starts with a directory separator, but not with drive-letter-colon, it still has a

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

On 07/11/2018 11:19, Johannes Schindelin wrote: [snip] >>> Hmm, this doesn't quite fit with the intended use of this >>> function! ;-) (even on windows!) >>> >>> I haven't looked very deeply, but doesn't this affect all >>> absolute paths in the config read by git_config_pathname(), >>> along

[PATCH v2] format-patch: respect --stat in cover letter's diffstat

Commit 43662b23ab (format-patch: keep cover-letter diffstat wrapped in 72 columns - 2018-01-24) uncondtionally sets stat width to 72 when generating diffstat for the cover letter, ignoring --stat from command line. But it should only do so when stat width is still default (i.e. stat_width == 0).

Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

On Tue, Nov 6, 2018 at 11:11 PM Jeff King wrote: > > On Tue, Nov 06, 2018 at 06:48:22PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > The implementation looks fine to me, but as noted in > > https://public-inbox.org/git/8736se6qyc@evledraar.gmail.com/ I > > wonder what the plausible end-game

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

On Wed, Nov 7, 2018 at 2:09 PM SZEDER Gábor wrote: > > On Wed, Nov 07, 2018 at 06:41:45PM +0900, Junio C Hamano wrote: > > * nd/i18n (2018-11-06) 16 commits > > - fsck: mark strings for translation > > - fsck: reduce word legos to help i18n > > - parse-options.c: mark more strings for

Git Test Coverage Report (Wednesday, Nov 7)

Here is the coverage report for today. Thanks, -Stolee [1] https://dev.azure.com/git/git/_build/results?buildId=251=logs --- pu: 381b31f0006e46fe041e7fc6e5f7b19da5ccd889 jch: ab76604d6537afa18c9d8588c08f699c1f539659 next: 8438c0b2453a7207c9c45756f5e37dfe283db602 master:

[PATCH 0/2] built-in rebase --autostash: fix regression

It was reported that the new, shiny built-in git rebase has a bug where it would detach the HEAD when it was not even necessary to detach it. Keeping with my fine tradition to first demonstrate what is the actual problem (and making it easy to verify my claim), this patch series first introduces

[PATCH 1/2] built-in rebase: demonstrate regression with --autostash

From: Johannes Schindelin An unnamed colleague of Ævar Arnfjörð Bjarmason reported a breakage where a `pull --rebase` (which did not really need to do anything but stash, see that nothing was changed, and apply the stash again) also detached the HEAD. This patch adds a minimal reproducer for

[PATCH 2/2] built-in rebase --autostash: leave the current branch alone if possible

From: Johannes Schindelin When we converted a `git reset --hard` call in the original Unix shell script to built-in code, we asked to reset the worktree and the index and explicitly *not* to detach the HEAD. By mistake, though, we still did. Let's fix this. Signed-off-by: Johannes Schindelin

Re: [PATCH 0/1] http: add support selecting http version

On Wed, 7 Nov 2018, Force.Charlie-I via GitGitGadget wrote: Normally, git doesn't need to set curl to select the HTTP version, it works fine without HTTP2. Adding HTTP2 support is a icing on the cake. Just a FYI: Starting with libcurl 7.62.0 (released a week ago), it now defaults to the

Re: Regression in rebase-in-C with rebase.autoStash=true

Hi Ævar, On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Oct 23 2018, Johannes Schindelin via GitGitGadget wrote: > > > Johannes Schindelin (2): > > rebase --autostash: demonstrate a problem with dirty submodules > > rebase --autostash: fix issue with dirty submodules > > >

[PATCH 0/1] http: add support selecting http version

Normally, git doesn't need to set curl to select the HTTP version, it works fine without HTTP2. Adding HTTP2 support is a icing on the cake. When http.version=20 is set, git will attempt to request the server using HTTP2. If the remote server does not support HTTP2, it is no different. Currently

[PATCH 1/1] http: add support selecting http version

From: Force Charlie Signed-off-by: Force Charlie --- http.c | 12 1 file changed, 12 insertions(+) diff --git a/http.c b/http.c index 3dc8c560d6..99cb04faba 100644 --- a/http.c +++ b/http.c @@ -48,6 +48,7 @@ char curl_errorstr[CURL_ERROR_SIZE]; static int curl_ssl_verify = -1;

Re: [PATCH v3 1/2] range-diff doc: add a section about output stability

On Wednesday, November 7, 2018 5:22:01 AM MST Ævar Arnfjörð Bjarmason wrote: > +OUTPUT STABILITY > + > + > +The output of the `range-diff` command is subject to change. It is > +intended to be human-readable porcelain output, not something that can > +be used across versions of Git

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

On Wed, Nov 07, 2018 at 06:41:45PM +0900, Junio C Hamano wrote: > * nd/i18n (2018-11-06) 16 commits > - fsck: mark strings for translation > - fsck: reduce word legos to help i18n > - parse-options.c: mark more strings for translation > - parse-options.c: turn some die() to BUG() > -

Re: Wildcard URL config matching

Hi Brian, On Mon, Nov 05, 2018 at 08:56:52PM +, brian m. carlson wrote: > In a272b9e70a ("urlmatch: allow globbing for the URL host part", > 2017-01-31), we added support for wildcard matching for URLs when > reading from .git/config. Now it's possible to specify an option like >

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

Ævar Arnfjörð Bjarmason writes: > On Wed, Nov 07 2018, Junio C Hamano wrote: > >> * ab/range-diff-no-patch (2018-11-07) 1 commit >> - range-diff: add a --no-patch option to show a summary >> >> "range-diff" learns the "--no-patch" option, which can be used to >> get a high-level overview

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

On Wed, Nov 07 2018, Junio C Hamano wrote: > * ab/range-diff-no-patch (2018-11-07) 1 commit > - range-diff: add a --no-patch option to show a summary > > "range-diff" learns the "--no-patch" option, which can be used to > get a high-level overview without the actual line-by-line patch >

[PATCH v3 0/2] range-diff: doc + regression fix

As Johannes notes this --no-patch option I wanted to add is something we had already, but is it turns out it was broken. So this is an entirely rewritten v3 (not bothering with the range-diff for it) which a) documents the output stability of stuff like --stat and the like (there isn't any) b)

[PATCH v3 1/2] range-diff doc: add a section about output stability

The range-diff command is already advertised as porcelain, but let's make it really clear that the output is completely subject to change, particularly when it comes to diff options such as --stat. Right now that option doesn't work, but fixing that is the subject of a later change.

[PATCH v3 2/2] range-diff: fix regression in passing along diff options

In 73a834e9e2 ("range-diff: relieve callers of low-level configuration burden", 2018-07-22) we broke passing down options like --no-patch, --stat etc. Fix that regression, and add a test for some of these options being passed down. As noted in a change leading up to this ("range-diff doc: add a

Re: build error on mac os 10.14.1

Solved, It is because the macOS SDK headers loss in 10.14.1. Need install command line tool 10.1 and install the header package in /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg So I think the git make configure need check the SDK header to get the correct

Re: [PATCH 1/1] Windows: force-recompile git.res for differing architectures

Hi, On Wed, 7 Nov 2018, Junio C Hamano wrote: > Johannes Sixt writes: > > > Am 07.11.18 um 02:32 schrieb Junio C Hamano: > >> Johannes Sixt writes: > >>> On Linux, when I recompile for a different architecture, CFLAGS would > >>> change, so I would have thought that GIT-CFLAGS were the

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Hi Hannes, On Tue, 6 Nov 2018, Johannes Sixt wrote: > Am 06.11.18 um 15:53 schrieb Johannes Schindelin via GitGitGadget: > > From: Johannes Schindelin > > > > On Windows, an absolute POSIX path needs to be turned into a Windows > > one. > > If I were picky, I would say that in a pure Windows

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Hi, On Tue, 6 Nov 2018, Duy Nguyen wrote: > On Tue, Nov 6, 2018 at 3:55 PM Johannes Schindelin via GitGitGadget > wrote: > > > > From: Johannes Schindelin > > > > On Windows, an absolute POSIX path needs to be turned into a Windows > > one. > > > > Signed-off-by: Johannes Schindelin > > --- >

Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path()

Hi, On Wed, 7 Nov 2018, Junio C Hamano wrote: > Ramsay Jones writes: > > > On 06/11/2018 14:53, Johannes Schindelin via GitGitGadget wrote: > >> From: Johannes Schindelin > >> > >> On Windows, an absolute POSIX path needs to be turned into a Windows > >> one. > >> > >> Signed-off-by:

Re: [PATCH v2] range-diff: add a --no-patch option to show a summary

Hi, On Wed, 7 Nov 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > diff --git a/builtin/range-diff.c b/builtin/range-diff.c > > index f01a0be851..05d1f6b6b6 100644 > > --- a/builtin/range-diff.c > > +++ b/builtin/range-diff.c > > @@ -16,11 +16,14 @@ int cmd_range_diff(int

Re: [PATCH] range-diff: add a --no-patch option to show a summary

Me again, On Wed, 7 Nov 2018, Johannes Schindelin wrote: > On Wed, 7 Nov 2018, Johannes Schindelin wrote: > > > On Wed, 7 Nov 2018, Johannes Schindelin wrote: > > > > > On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > > > > > On Tue, Nov 06 2018, Johannes Schindelin wrote: > > > > >

Re: [PATCH] range-diff: add a --no-patch option to show a summary

Hi Ævar, On Wed, 7 Nov 2018, Johannes Schindelin wrote: > On Wed, 7 Nov 2018, Johannes Schindelin wrote: > > > On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > > > On Tue, Nov 06 2018, Johannes Schindelin wrote: > > > > > > > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > >

[Market Info] Now is your chance to exhibit in Japan!

Dear International Sales & Marketing Director Zhejiang Wuchuan Industrial Co., Ltd, Hello, this is Eiichi Hasegawa from LIFESTYLE EXPO TOKYO 2019 Show Management. Today, I would like to share the information of the growing Japanese gift market, and the buyers that you can meet at our show.

Re: [PATCH] range-diff: add a --no-patch option to show a summary

Hi Ævar, On Wed, 7 Nov 2018, Johannes Schindelin wrote: > On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > On Tue, Nov 06 2018, Johannes Schindelin wrote: > > > > > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > > > >> On Mon, Nov 05 2018, Eric Sunshine wrote: > > >> > > >> >

Re: [PATCH] range-diff: add a --no-patch option to show a summary

Hi Ævar, On Tue, 6 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > On Tue, Nov 06 2018, Johannes Schindelin wrote: > > > On Mon, 5 Nov 2018, Ævar Arnfjörð Bjarmason wrote: > > > >> On Mon, Nov 05 2018, Eric Sunshine wrote: > >> > >> > On Mon, Nov 5, 2018 at 3:07 PM Ævar Arnfjörð Bjarmason > >> >

What's cooking in git.git (Nov 2018, #03; Wed, 7)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

  1   2   >