Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Johannes Sixt writes: > The patch does add a new runtime dependency on libcrypto.dll in my > environment. I would be surprised if it does not also with your modern > build tools. > > I haven't had time to compare test suite runtimes. > >> I'm open to the argument that it doesn't

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Hey Junio, On Tue, Feb 14, 2017 at 12:44 AM, Junio C Hamano wrote: > René Scharfe writes: > >> Initializing to NULL is still the correct thing to do, of course -- >> together with removing the conditionals (or at least the negations). > > So, let's give Pranit a

Re: [RFC PATCH] show decorations at the end of the line

On Mon, Feb 13, 2017 at 12:30 AM, Junio C Hamano wrote: > > An obvious downside is that people (against all recommendations) are > likely to have written a loose script expecting the --oneline format > is cast in stone. Actually, I don't believe that is the case wrt

Re: [PATCH] squash! completion: fill COMPREPLY directly when completing refs

On Fri, Feb 10, 2017 at 10:44 PM, Junio C Hamano wrote: > Should I expect a reroll to come, or is this the only fix-up to the > series that begins at <20170203025405.8242-1-szeder@gmail.com>? > > No hurries. Yes, definitely. I found a minor bug in the middle of the

Re: Incorrect pipe for git log graph when using --name-status option

hIpPy writes: > The `git log` command with `graph` and pretty format works correctly > as expected. > > $ git log --graph --pretty=format:'%h' -2 > * 714a14e > * 87dce5f > > > However, with `--name-status` option added, there is a pipe > incorrectly placed after the commit

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Arif Khokar writes: > ... I > still think it would be better to be able to list the message-id > values in the header or body of the cover letter message of a patch > series (preferably the former) in order to facilitate downloading the > patches via NNTP from gmane or

[PATCH] completion: restore removed line continuating backslash

Recent commit 1cd23e9e0 (completion: don't use __gitdir() for git commands, 2017-02-03) rewrapped a couple of long lines, and while doing so it inadvertently removed a '\' from the end of a line, thus breaking completion for 'git config remote.name.push '. Signed-off-by: SZEDER Gábor

Re: [PATCH] clean: use warning_errno() when appropriate

On Mon, Feb 13, 2017 at 10:34:06AM -0800, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > > > All these warning() calls are preceded by a system call. Report the > > actual error to help the user understand why we fail to remove > > something. > > I think this patch

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

René Scharfe writes: > Initializing to NULL is still the correct thing to do, of course -- > together with removing the conditionals (or at least the negations). So, let's give Pranit a concrete "here is what we want to see squashed in", while you guys discuss peculiarity with

Re: git remote rename problem with trailing \\ for remote.url config entries (on Windows)

Marc Strapetz writes: > One of our users has just reported that: > > $ git remote rename origin origin2 > > will turn following remote entry: > > [remote "origin"] > url = c:\\repo\\ > fetch = +refs/heads/*:refs/remotes/origin/* > > into following entry for

Re: [PATCH] clean: use warning_errno() when appropriate

Nguyễn Thái Ngọc Duy writes: > All these warning() calls are preceded by a system call. Report the > actual error to help the user understand why we fail to remove > something. I think this patch is probably correct in the current code, but I say this only after following

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Am 13.02.2017 um 17:23 schrieb Johannes Schindelin: > Hi René, > > On Fri, 10 Feb 2017, René Scharfe wrote: > >> Am 10.02.2017 um 15:20 schrieb Johannes Schindelin: >>> It is curious that only MacOSX builds trigger an error about this, both >>> GCC and Clang, but not Linux GCC nor Clang (see >>>

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Small regression on Windows

Please type this, preferably outside of any repo to avoid that it is changed; note the command typo: git -c help.autocorrect=40 ceckout Git waits for 4 seconds, but does not write anything until just before it exits. It bisects to a9b8a09c3c30886c79133da9f48ef9f98c21c3b2 is the first bad

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Am 10.02.2017 um 17:04 schrieb Jeff King: On Fri, Feb 10, 2017 at 04:49:02PM +0100, Johannes Schindelin wrote: I think this is only half the story. A heavy-sha1 workload is faster, which is good. But one of the original reasons to prefer blk-sha1 (at least on Linux) is that resolving

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Hi Hannes, On Sat, 11 Feb 2017, Johannes Sixt wrote: > Am 10.02.2017 um 00:41 schrieb Junio C Hamano: > > Johannes Schindelin writes: > > > > > From: Jeff Hostetler > > > > > > Use OpenSSL's SHA-1 routines rather than builtin block-sha1 > > >

git remote rename problem with trailing \\ for remote.url config entries (on Windows)

One of our users has just reported that: $ git remote rename origin origin2 will turn following remote entry: [remote "origin"] url = c:\\repo\\ fetch = +refs/heads/*:refs/remotes/origin/* into following entry for which the url is skipped: [remote "origin2"] [remote

Re: [PATCH] fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C

Hi René, On Fri, 10 Feb 2017, René Scharfe wrote: > Am 10.02.2017 um 15:20 schrieb Johannes Schindelin: > > It is curious that only MacOSX builds trigger an error about this, both > > GCC and Clang, but not Linux GCC nor Clang (see > > https://travis-ci.org/git/git/jobs/200182819#L1152 for

Re: Bug in 'git describe' if I have two tags on the same commit.

On Sun, Feb 12, 2017 at 01:15:22PM +0100, Istvan Pato wrote: > I didn't get back the latest tag by 'git describe --tags --always' if > I have two tags on the same commit. > > // repository ppa:git-core/ppa > > (master)⚡ % cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=16.04 >

[PATCH 03/11] files-backend: add files_path()

This will be the replacement for both git_path() and git_path_submodule() in this file. The idea is backend takes a git path and use that, oblivious of submodule, linked worktrees and such. This is the middle step towards that. Eventually the "submodule" field in 'struct files_ref_store' should

[PATCH 05/11] refs.c: share is_per_worktree_ref() to files-backend.c

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 6 -- refs/refs-internal.h | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/refs.c b/refs.c index f03dcf58b..2cacd934e 100644 --- a/refs.c +++ b/refs.c @@ -489,12 +489,6 @@ int

[PATCH 07/11] files-backend: remove the use of git_path()

Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of deciding what goes where. The end goal is to pass $GIT_DIR only. A refs "view" of a linked worktree is a logical ref store that combines two files backends together. (*) Not entirely true since strbuf_git_path_submodule() still

[PATCH 02/11] files-backend: convert git_path() to strbuf_git_path()

git_path() and friends are going to be killed in files-backend.c in near future. And because there's a risk with overwriting buffer in git_path(), let's convert them all to strbuf_git_path(). We'll have easier time killing/converting strbuf_git_path() then because we won't have to worry about

[PATCH 01/11] refs-internal.c: make files_log_ref_write() static

Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10) but probably never used outside refs-internal.c Signed-off-by: Nguyễn Thái Ngọc Duy --- refs/files-backend.c | 3 +++ refs/refs-internal.h | 4 2 files changed, 3 insertions(+), 4 deletions(-) diff

[PATCH 04/11] files-backend: replace *git_path*() with files_path()

This centralizes all path rewriting of files-backend.c in one place so we have easier time removing the path rewriting later. There could be some hidden indirect git_path() though, I didn't audit the code to the bottom. Side note: set_worktree_head_symref() is a bad boy and should not be in

[PATCH 06/11] refs-internal.h: correct is_per_worktree_ref()

All refs outside refs/ directory is per-worktree, not just HEAD. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs/refs-internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/refs-internal.h b/refs/refs-internal.h index f4aed49f5..69d02b6ba 100644 ---

[PATCH 09/11] refs: move submodule code out of files-backend.c

files-backend is now initialized with a $GIT_DIR. Converting a submodule path to where real submodule gitdir is located is done in get_ref_store(). The new code in init_submodule_ref_store() is basically a copy of strbuf_git_path_submodule(). This gives a slight performance improvement for

[PATCH 08/11] refs.c: factor submodule code out of get_ref_store()

This code is going to be expanded a bit soon. Keep it out for better readability later. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/refs.c b/refs.c index 2cacd934e..8ef7a52ba 100644

[PATCH 10/11] files-backend: remove submodule_allowed from files_downcast()

Since submodule or not is irrelevant to files-backend after the last patch, remove the parameter from files_downcast() and kill files_assert_main_repository(). PS. This implies that all ref operations are allowed for submodules. But we may need to look more closely to see if that's really true...

[PATCH 11/11] refs: split and make get_*_ref_store() public API

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 59 ++-- refs.h | 13 refs/files-backend.c | 2 +- refs/refs-internal.h | 12 --- 4 files changed, 48 insertions(+), 38

[PATCH/RFC 00/11] Remove submodule from files-backend.c

This is on top of mh/submodule-hash, it: - centralizes path manipulation around submodule, $GIT_DIR... in files-backend.c to a new function files_path() with the intention to make it easier to change later. files_path() is destined to become strbuf_addbuf(, refs->gitdir);

Re: Hi

Hello, I wish to seek for your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley in Uijeongbu, South Korea. Please contact me for details, God bless you.

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Arif, On Mon, 13 Feb 2017, Arif Khokar wrote: > On 02/10/2017 11:10 AM, Johannes Schindelin wrote: > > > > On Wed, 24 Aug 2016, Johannes Schindelin wrote: > > > > I recently adapted an old script I had to apply an entire patch > > > series given the GMane link to its cover letter: > > > > >

[PATCH] clean: use warning_errno() when appropriate

All these warning() calls are preceded by a system call. Report the actual error to help the user understand why we fail to remove something. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/clean.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [RFC PATCH] show decorations at the end of the line

Linus Torvalds writes: > On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds > wrote: >> >> I've signed off on this, because I think it's an "obvious" improvement, >> but I'm putting the "RFC" in the subject line because this is clearly

Client Relationship Manager!

Dalian machine toolz limited seeks to recruit full and part time Managers, Representatives, Partners, Expatriates and Consultancy firms to render expertise and non-expertise services in our overseas new and emerging markets / offices located in Canada, Mexico and USA. If you are Interested

<    1   2