What's cooking in git.git (Sep 2017, #03; Fri, 15)

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. We are at week #6 of this cycle.

Re: git diff --name-status for deleted files

Gene Thomas writes: > Junio, >Thanks for your reply. So git is essentially doing a >"git commit" when I "git rm". No. You'd probably need to read a bit more on Git; unlike other systems like CVS and SVN, where you only have two states (i.e. committed

RE: git diff --name-status for deleted files

Junio, Thanks for your reply. So git is essentially doing a "git commit" when I "git rm". Gene. -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Friday, 15 September 2017 2:58 PM To: Gene Thomas Cc: git@vger.kernel.org Subject: Re:

Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

Kevin Willford writes: > 1. Does this statement, "I only care about the files in this > sparse checkout, and do not concern me with anything else", mean > that git should not change files outside the sparse-checkout whether > that be in the working directory or in the

[PATCH v3] commit-template: change a message to be more intuitive

It's not good to use the phrase 'do not touch' to convey the information that the cut-line should not be modified or removed as it could possibly be mis-interpreted by a person who doesn't know that the word 'touch' has the meaning of 'tamper with'. Further, it could make translations a little

Re: [PATCH v4 3/4] imap_send: setup_curl: retreive credentials if not set in config file

Nicolas Morey-Chaisemartin writes: > > + if (cred.username) > + if (res == CURLE_OK) > + credential_approve(); > +#if LIBCURL_VERSION_NUM >= 0x070d01 > + else if (res == CURLE_LOGIN_DENIED) > +#else > +

Re: [PATCH v4 3/4] imap_send: setup_curl: retreive credentials if not set in config file

Nicolas Morey-Chaisemartin writes: > + if (cred.username) > + if (res == CURLE_OK) > + credential_approve(); > +#if LIBCURL_VERSION_NUM >= 0x070d01 > + else if (res == CURLE_LOGIN_DENIED) A slight tangent. This is

Re: [PATCH 00/20] Read `packed-refs` using mmap()

On 09/14/2017 10:23 PM, Johannes Schindelin wrote: > On Wed, 13 Sep 2017, Michael Haggerty wrote: > >> * `mmap()` the whole file rather than `read()`ing it. > > On Windows, a memory-mapped file cannot be renamed. As a consequence, the > following tests fail on `pu`: > > [...] Thanks for your

Re: git diff --name-status for deleted files

Gene Thomas writes: > Hello, > "git diff -name-status" is useful to list the files one > has changed but it does not list file that one has > deleted with "git rm". It would be really handy if it > did. I am using git 2.9.3 on Ubuntu Linux

Git 2.14.1: t6500: error during test on musl libc

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there, While bumping Git's version for our Linux distribution to 2.14.1, I've run in to a new test failure in t6500-gc.sh. This is the output of the failing test with debug=t verbose=t: expecting success: # make sure we run a

Re: [PATCH 2/3] merge-base: return fork-point outside reflog

Michael J Gruber writes: > In fact, per documentation "--fork-point" looks at the reflog in > addition to doing the usual walk from the tip. The original design > description in d96855ff51 ("merge-base: teach "--fork-point" mode", > 2013-10-23) describes this as computing from a

Re: [PATCH 0/4] Fixes from the per-repository object store series

Jonathan Nieder writes: > This is a continuation of the series at [1]. That was part 1 --- > you can think of this as part 0, since it contains the simplest and > least controversial part of the series --- each patch in this series > is a bugfix in its own right. > > Patch 1

Re: [PATCH v2] commit-template: change a message to be more intuitive

Jeff King writes: > # >8 > # Do not modify or remove the line above. > # Everything below will be ignored. > > (I might say "everything below it" to be more precise). > > I dunno. We are deep in bikeshed territory here, and I

Re: [PATCH v2] commit-template: change a message to be more intuitive

On Thu, 2017-09-14 at 09:36 +0200, Michael J Gruber wrote: > > Also, given all the translations that we have, it seems somewhat strange > to try and foresee and workaround possible misunderstandings of commonly > used English phrases. In case you're trying to say that "Translators have

Re: commit-msg hook does not run on merge with --no-ff option

On Tue, 2017-09-12 at 13:24 -0500, Joseph Dunne wrote: > Sorry I don't understand your question. The commit-msg hook runs > properly in all cases except when I perform a merge with the --no-ff > option enabled. > It's working just as the documentation says it does (emphasis mine), This

Dearest/Käraste

Dearest, I am Mrs. Asana Hajraf and I am married to Mr. Hassan Hajraf from kuwait for 19 years without a child and my husband died in 2014. I am contacting you to let you know my desire to donate the sum of $4.5 million to charities in your country which I inherited from my late husband. Due to

Re: [PATCH 7/7] config: flip return value of store_write_*()

On Wed, Sep 13, 2017 at 02:25:28PM -0700, Jonathan Nieder wrote: > > Let's flip them to follow the usual write() conventions and > > update all callers. As these are local to config.c, it's > > unlikely that we'd have new callers in any topics in flight > > (which would be silently broken by our

Re: [PATCH 6/7] notes-merge: use ssize_t for write_in_full() return value

On Wed, Sep 13, 2017 at 02:20:35PM -0700, Jonathan Nieder wrote: > > --- a/notes-merge.c > > +++ b/notes-merge.c > > @@ -302,7 +302,7 @@ static void write_buf_to_worktree(const struct > > object_id *obj, > > fd = xopen(path, O_WRONLY | O_EXCL | O_CREAT, 0666); > > > > while (size > 0)

Re: [PATCH 3/7] avoid "write_in_full(fd, buf, len) != len" pattern

On Wed, Sep 13, 2017 at 02:14:30PM -0700, Jonathan Nieder wrote: > >I really wish every "write_in_full()" user would just > >check against "<0" now, but this fixes the nasty and > >stupid ones. > > Ok, you convinced me. > > Should we add a comment to cache.h as well

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

On Wed, Sep 13, 2017 at 02:09:27PM -0700, Jonathan Nieder wrote: > > We ask to write 41 bytes and make sure that the return value > > is at least 41. This is the same "dangerous" pattern that > > was fixed in the prior commit (wherein a negative return > > value is promoted to unsigned), though

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

On Thu, Sep 14, 2017 at 12:31:38AM +0100, Ramsay Jones wrote: > > Hmm, about three or four years ago, I spent two or three evenings > > getting git to compile -Wextra clean. I remember the signed/unsigned > > issue was the cause of a large portion of the warnings issued by > > the compiler. I was

Re: [idea] File history tracking hints

From: "Johannes Schindelin" Hi Philip, On Mon, 11 Sep 2017, Philip Oakley wrote: From: "Pavel Kretov" > Hi all, > > Excuse me if the topic I'm going to raise here has been already > discussed > on the mailing list, forums, or IRC, but I

Re: [PATCH 1/2] test-lib: group system specific FIFO tests by system

Hi Michael, On Thu, 14 Sep 2017, Michael J Gruber wrote: > test-lib determines whether a file-system supports FIFOs and needs to do > special casing for CYGWIN and MINGW. This separates those system > specific settings from those at more central place. > > Set mkfifo() to false in the central

Re: [PATCH 00/20] Read `packed-refs` using mmap()

Hi Michael, On Thu, 14 Sep 2017, Michael Haggerty wrote: > On 09/13/2017 07:15 PM, Michael Haggerty wrote: > > [...] > > * `mmap()` the whole file rather than `read()`ing it. > > [...] > > Apparently this doesn't work on Windows, because the `snapshot` is > keeping the `packed-refs` file open

git diff --name-status for deleted files

Hello, "git diff -name-status" is useful to list the files one has changed but it does not list file that one has deleted with "git rm". It would be really handy if it did. I am using git 2.9.3 on Ubuntu Linux 16.10. Yours Sincerely, Gene Thomas.

Re: RFC v3: Another proposed hash function transition plan

Hi Jonathan, On Thu, 14 Sep 2017, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > On Wed, 13 Sep 2017, Jonathan Nieder wrote: > > >> [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html, > > > > I had read this short after it was published, and had missed the updates. > > One

git fast-export/import bug with -M -C

The commands should be self explanatory. 0.2.0~20 is the first commit where the reconstructed repository diverges, that commit had a simultaneous copy and edit of one file. It seems that copy/rename detection, enabled with -M -C is confused by this. I reproduced it with git 2.14 next @ 8fa685d.

Re: RFC v3: Another proposed hash function transition plan

Hi, On Thu, 14 Sep 2017, demerphq wrote: > On 14 September 2017 at 17:23, Johannes Schindelin > wrote: > > > > SHA-256 has been hammered on a lot more than SHA3-256. > > Last year that was even more true of SHA1 than it is true of SHA-256 > today. I hope you are

Re: [PATCH 00/20] Read `packed-refs` using mmap()

Hi Michael, On Wed, 13 Sep 2017, Michael Haggerty wrote: > * `mmap()` the whole file rather than `read()`ing it. On Windows, a memory-mapped file cannot be renamed. As a consequence, the following tests fail on `pu`: t1400-update-ref.sh t1404-update-ref-errors.sh t1405-main-ref-store.sh

Re: RFC v3: Another proposed hash function transition plan

Johannes Schindelin wrote: > On Wed, 13 Sep 2017, Jonathan Nieder wrote: >> As a side note, I am probably misreading, but I found this set of >> paragraphs a bit condescending. It sounds to me like you are saying >> "You are making the wrong choice of hash function and everything else >> you are

Re: RFC v3: Another proposed hash function transition plan

Hi Linus, On Wed, 13 Sep 2017, Linus Torvalds wrote: > On Wed, Sep 13, 2017 at 6:43 AM, demerphq wrote: > > > > SHA3 however uses a completely different design where it mixes a 1088 > > bit block into a 1600 bit state, for a leverage of 2:3, and the excess > > is *preserved

Re: RFC v3: Another proposed hash function transition plan

Hi, Johannes Schindelin wrote: > On Wed, 13 Sep 2017, Jonathan Nieder wrote: >> [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html, > > I had read this short after it was published, and had missed the updates. > One link in particular caught my eye: > >

Re: RFC v3: Another proposed hash function transition plan

Hi Jonathan, On Wed, 13 Sep 2017, Jonathan Nieder wrote: > [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html, I had read this short after it was published, and had missed the updates. One link in particular caught my eye: https://eprint.iacr.org/2012/476 Essentially, the

Re: [PATCH v2] test-lib: don't use ulimit in test prerequisites on cygwin

Ramsay Jones wrote: > On cygwin (and MinGW), the 'ulimit' built-in bash command does not have > the desired effect of limiting the resources of new processes, at least > for the stack and file descriptors. However, it always returns success > and leads to several test prerequisites being

Re: [PATCH v5 25/40] external-odb: add 'get_direct' support

On Thu, 14 Sep 2017 10:39:35 +0200 Christian Couder wrote: > From the following email: > > https://public-inbox.org/git/20170804145113.5ceaf...@twelve2.svl.corp.google.com/ > > it looks like his work is fundamentally about changing the rules of > connectivity

Re: Rebase & submodules

On Thu, Sep 14, 2017 at 10:57 AM, Nicolas Morey-Chaisemartin wrote: > Without changing your workflow too much, If you mean to imply that you have other recommendations if I'm willing to change my workflow, then please by all means share them. I'm very interested. I'm

Re: [PATCH 2/2] test-lib: ulimit does not limit on CYGWIN and MINGW

On 14/09/17 15:52, Michael J Gruber wrote: > ulimit succeeds (by return value) but does not limit on some systems. > > Set ulimit() to false on these systems so that we do not rely on its > output nor effect. As an intended side-effect, ulimit based > prerequisites are set correctly (to

[PATCH v2] test-lib: don't use ulimit in test prerequisites on cygwin

On cygwin (and MinGW), the 'ulimit' built-in bash command does not have the desired effect of limiting the resources of new processes, at least for the stack and file descriptors. However, it always returns success and leads to several test prerequisites being erroneously set to true. Add a

[PATCH v2] commit-tree: do not complete line in -F input

"git commit-tree -F ", unlike "cat | git commit-tree" (i.e. feeding the same contents from the standard input), added a missing final newline when the input ended in an incomplete line. Correct this inconsistency by leaving the incomplete line as-is, as erring on the side of not touching the

Re: RFC v3: Another proposed hash function transition plan

On 09/14, Johannes Schindelin wrote: > Hi Jonathan, > > On Wed, 13 Sep 2017, Jonathan Nieder wrote: > > > As a side note, I am probably misreading, but I found this set of > > paragraphs a bit condescending. It sounds to me like you are saying > > "You are making the wrong choice of hash

Re: [PATCH 00/20] Read `packed-refs` using mmap()

On 09/13/2017 07:15 PM, Michael Haggerty wrote: > [...] > * `mmap()` the whole file rather than `read()`ing it. > [...] Apparently this doesn't work on Windows, because the `snapshot` is keeping the `packed-refs` file open too long, so the new file can't be renamed on top of it. I didn't realize

Re: Rebase & submodules

Le 14/09/2017 à 17:39, Robert Dailey a écrit : > So I often will have a submodule that points to one of my own forks, > because I will have work done on a feature branch that hasn't been > merged upstream yet. Assuming this merge takes a long time to get > approved, I will occasionally rebase my

Re: RFC v3: Another proposed hash function transition plan

On 14 September 2017 at 17:23, Johannes Schindelin wrote: > Hi Junio, > > On Thu, 14 Sep 2017, Junio C Hamano wrote: > >> Jonathan Nieder writes: >> >> > In other words, a long lifetime for the hash absolutely is a design >> > goal. Coping well

Rebase & submodules

So I often will have a submodule that points to one of my own forks, because I will have work done on a feature branch that hasn't been merged upstream yet. Assuming this merge takes a long time to get approved, I will occasionally rebase my topic branch to keep things up to date and clean.

Re: RFC v3: Another proposed hash function transition plan

Hi Junio, On Thu, 14 Sep 2017, Junio C Hamano wrote: > Jonathan Nieder writes: > > > In other words, a long lifetime for the hash absolutely is a design > > goal. Coping well with an unexpectedly short lifetime for the hash is > > also a design goal. > > > > If the hash

[PATCH 2/2] test-lib: ulimit does not limit on CYGWIN and MINGW

ulimit succeeds (by return value) but does not limit on some systems. Set ulimit() to false on these systems so that we do not rely on its output nor effect. As an intended side-effect, ulimit based prerequisites are set correctly (to "not-have") on these systems. Reported-by: Ramsay Jones

[PATCH 1/2] test-lib: group system specific FIFO tests by system

test-lib determines whether a file-system supports FIFOs and needs to do special casing for CYGWIN and MINGW. This separates those system specific settings from those at more central place. Set mkfifo() to false in the central system specific place so that the same test works everywhere.

Re: [PATCH v2] commit-template: change a message to be more intuitive

On Thu, Sep 14, 2017 at 07:47:51PM +0530, Kaartic Sivaraam wrote: > > > - const char *explanation = _("Do not touch the line above.\nEverything > > > below will be removed."); > > > + const char *explanation = _("Do not modify or remove the line > > > above.\nEverything below will be

Re: [PATCH 0/3] merge-base --fork-point fixes

On Thu, Sep 14, 2017 at 03:15:17PM +0200, Michael J Gruber wrote: > merge-base --fork-point does not quite work as advertised when the > reflog is empty or partial. This series brings it in line with the > documentation and, hopefully, with the original intent. > > Michael J Gruber (3): >

Re: [PATCH 3/3] merge-base: find fork-point outside partial reflog

On Thu, Sep 14, 2017 at 03:15:20PM +0200, Michael J Gruber wrote: > In fork-point mode, merge-base adds the commit at refname to a list of > candidates to walk from only when the reflog is empty. Therefore, it > fails to find merge bases that are descendants of the most recent reflog > entry. >

Re: [PATCH 1/3] t6010: test actual test output

On Thu, Sep 14, 2017 at 03:15:18PM +0200, Michael J Gruber wrote: > 4f21454b55 ("merge-base: handle --fork-point without reflog", > 2016-10-12) introduced a fix for merge-base --fork-point without reflog > and a test. While that test is fine, it did not update expected nor actual > output and

RE: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

> From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Wednesday, September 13, 2017 4:18 PM > > Jacob Keller writes: > > > By definition if you do a sparse checkout, you're telling git "I only > > care about the files in this sparse checkout, and do not concern me >

Re: [PATCH v2] commit-template: change a message to be more intuitive

On Thursday 14 September 2017 01:06 PM, Michael J Gruber wrote: Kaartic Sivaraam venit, vidit, dixit 13.09.2017 15:05: void wt_status_add_cut_line(FILE *fp) { - const char *explanation = _("Do not touch the line above.\nEverything below will be removed."); + const char

Re: [PATCH 0/3] merge-base --fork-point fixes

Hi Michael, On Thu, 14 Sep 2017, Michael J Gruber wrote: > merge-base --fork-point does not quite work as advertised when the > reflog is empty or partial. This series brings it in line with the > documentation and, hopefully, with the original intent. Thank you so much for working on this. I

[PATCH 0/3] merge-base --fork-point fixes

merge-base --fork-point does not quite work as advertised when the reflog is empty or partial. This series brings it in line with the documentation and, hopefully, with the original intent. Michael J Gruber (3): t6010: test actual test output merge-base: return fork-point outside reflog

[PATCH 1/3] t6010: test actual test output

4f21454b55 ("merge-base: handle --fork-point without reflog", 2016-10-12) introduced a fix for merge-base --fork-point without reflog and a test. While that test is fine, it did not update expected nor actual output and tested that of the previous test instead. Fix the test to test the merge-base

[PATCH 3/3] merge-base: find fork-point outside partial reflog

In fork-point mode, merge-base adds the commit at refname to a list of candidates to walk from only when the reflog is empty. Therefore, it fails to find merge bases that are descendants of the most recent reflog entry. Add the commit at the tip unconditionally so that a merge base on the history

[PATCH 2/3] merge-base: return fork-point outside reflog

4f21454b55 ("merge-base: handle --fork-point without reflog", 2016-10-12) fixed the case without reflog, but only partially: The original code checks whether the merge base candidates are from the list that we started with, which was the list of reflog entries before 4f21454b55 and the list of

WINNING NOTIFICATION

Congratulation you have won 85,000,000.00GBP For Claim email:i...@winningsclaimsoffice.com

Re: [PATCH 2/4] push, fetch: error out for submodule entries not pointing to commits

On Tue, Sep 12, 2017 at 10:30:27AM -0700, Jonathan Nieder wrote: > From: Stefan Beller > > The check_has_commit helper uses resolves a submodule entry to a > commit, when validating its existence. As a side effect this means > tolerates a submodule entry pointing to a tag,

Re: RFC v3: Another proposed hash function transition plan

Hi Jonathan, On Wed, 13 Sep 2017, Jonathan Nieder wrote: > As a side note, I am probably misreading, but I found this set of > paragraphs a bit condescending. It sounds to me like you are saying > "You are making the wrong choice of hash function and everything else > you are describing is

Re: how to remove from history just *one* version of a file/dir?

On Thu, Sep 14, 2017 at 07:32:11AM -0400, Robert P. J. Day wrote: > [is this the right place to ask questions about git usage? or is > there a different forum where one can submit possibly embarrassingly > silly questions?] No, this is the right place for embarrassing questions. :) > say,

Re: should "git tag" option of "-a" conflict with "-s", "-u"?

On Thu, Sep 14, 2017 at 06:08:10AM -0400, Robert P. J. Day wrote: > just noticed in "man git-tag": > > 1) "-a" explicitly claims to create an unsigned tag > 2) both "-s" and "-u" both claim to create signed tags > > should that mean that it should be an error to try to use "-a" in >

how to remove from history just *one* version of a file/dir?

[is this the right place to ask questions about git usage? or is there a different forum where one can submit possibly embarrassingly silly questions?] i've been perusing "git filter-branch", and i'm curious if i have the right idea about how to very selectively get rid of some useless

Re: [PATCH v5 10/40] Add initial external odb support

On Thu, Aug 3, 2017 at 9:34 PM, Junio C Hamano wrote: > Christian Couder writes: > >> diff --git a/external-odb.h b/external-odb.h >> new file mode 100644 >> index 00..9989490c9e >> --- /dev/null >> +++ b/external-odb.h >> @@ -0,0 +1,8 @@ >>

should "git tag" option of "-a" conflict with "-s", "-u"?

just noticed in "man git-tag": 1) "-a" explicitly claims to create an unsigned tag 2) both "-s" and "-u" both claim to create signed tags should that mean that it should be an error to try to use "-a" in combination with either of "-u" or "-s"? the synopsis does suggest that you can use

Re: [PATCH v5 14/40] external-odb: accept only blobs for now

On Thu, Aug 3, 2017 at 9:52 PM, Junio C Hamano wrote: > Christian Couder writes: > >> The mechanism to decide which blobs should be sent to which >> external object database will be very simple for now. >> If the external odb helper support any

Re: [PATCH v5 13/40] external odb: add 'put_raw_obj' support

On Thu, Aug 3, 2017 at 9:50 PM, Junio C Hamano wrote: > Christian Couder writes: > >> Add support for a 'put_raw_obj' capability/instruction to send new >> objects to an external odb. Objects will be sent as they are (in >> their 'raw' format). They

Re: [PATCH v5 25/40] external-odb: add 'get_direct' support

On Thu, Aug 3, 2017 at 11:40 PM, Junio C Hamano wrote: > Christian Couder writes: > >> This implements the 'get_direct' capability/instruction that makes >> it possible for external odb helper scripts to pass blobs to Git >> by directly writing them

Re: [PATCH] test-lib: don't use ulimit in test prerequisites on cygwin

Jonathan Nieder venit, vidit, dixit 13.09.2017 21:20: > Ramsay Jones wrote: > >> On cygwin (and MinGW), the 'ulimit' built-in bash command does not have >> the desired effect of limiting the resources of new processes, at least >> for the stack and file descriptors. However, it always returns

Re: merge-base not working as expected when base is ahead

Ekelhart Jakob venit, vidit, dixit 13.09.2017 17:07: > Dear Git, > > git merge-base --fork-point "master" not working if master is already newer > then my current branch. > Very oddly it seems to work whenever you had the expected commit checked out > previously - what made it very tricky to

[PATCH v4 0/4] imap-send: Fix and enable curl by default

Changes since v3: - Fix return code in patch #1 - Reword patch#4 Nicolas Morey-Chaisemartin (4): imap-send: return with error if curl failed imap-send: add wrapper to get server credentials if needed imap_send: setup_curl: retreive credentials if not set in config file imap-send: use curl

[PATCH v4 1/4] imap-send: return with error if curl failed

curl_append_msgs_to_imap always returned 0, whether curl failed or not. Return a proper status so git imap-send will exit with an error code if something wrong happened. Signed-off-by: Nicolas Morey-Chaisemartin --- imap-send.c | 2 +- 1 file changed, 1

[PATCH v4 3/4] imap_send: setup_curl: retreive credentials if not set in config file

Up to this point, the curl mode only supported getting the username and password from the gitconfig file while the legacy mode could also fetch them using the credential API. Signed-off-by: Nicolas Morey-Chaisemartin --- imap-send.c | 18 -- 1

[PATCH v4 4/4] imap-send: use curl by default when possible

Set curl as the runtime default when it is available. When linked against older curl versions (< 7_34_0) or without curl, use the legacy imap implementation. The goal is to validate feature parity between the legacy and the curl implementation, deprecate the legacy implementation later on and in

[PATCH v4 2/4] imap-send: add wrapper to get server credentials if needed

Signed-off-by: Nicolas Morey-Chaisemartin --- imap-send.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/imap-send.c b/imap-send.c index b5e332420a..1b8fbbd545 100644 --- a/imap-send.c +++ b/imap-send.c @@

Re: [PATCH v5 19/40] lib-httpd: add upload.sh

On Thu, Aug 3, 2017 at 10:07 PM, Junio C Hamano wrote: > Christian Couder writes: > >> +OLDIFS="$IFS" >> +IFS='&' >> +set -- $QUERY_STRING >> +IFS="$OLDIFS" >> + >> +while test $# -gt 0 >> +do >> +key=${1%=*} >> +val=${1#*=} > > When you see

BUSINESS PROPOSAL

Please I like you to keep this proposal as a top secret and delete it if you are not interested and get back to me if you are interested for details as regards to the transfer of $24,500,000 to you. This money initially belongs to a Libyan client who died in the libya crisis and had no

Re: [PATCH v2] commit-template: change a message to be more intuitive

Kaartic Sivaraam venit, vidit, dixit 13.09.2017 15:05: > It's not good to use the phrase 'do not touch' to convey the information > that the cut-line should not be modified or removed as it could possibly > be mis-interpreted by a person who doesn't know that the word 'touch' has > the meaning of

Re: [PATCH v5 11/40] odb-helper: add odb_helper_init() to send 'init' instruction

On Sun, Sep 10, 2017 at 2:12 PM, Lars Schneider wrote: > >> On 03 Aug 2017, at 10:18, Christian Couder >> wrote: >> >> +static void parse_capabilities(char *cap_buf, >> +unsigned int *supported_capabilities, >> +

Re: [PATCH v5 12/40] t0400: add 'put_raw_obj' instruction to odb-helper script

On Sun, Sep 10, 2017 at 2:12 PM, Lars Schneider wrote: > >> On 03 Aug 2017, at 10:18, Christian Couder >> wrote: >> >> To properly test passing objects from Git to an external odb >> we need an odb-helper script that supports a 'put' >>

Re: [PATCH v5 00/40] Add initial experimental external ODB support

On Sun, Sep 10, 2017 at 2:30 PM, Lars Schneider wrote: > >> On 03 Aug 2017, at 10:18, Christian Couder >> wrote: >> >> ... >> >> * The "helpers" (registered commands) >> >> Each helper manages access to one external ODB. >> >> There are 2