[PATCH 0/2] fix git-svn HTTP tests under Apache 2.4

This resurrects the series started by Michael in April 2015 at: https://public-inbox.org/git/cover.1428505184.git@drmicha.warpmail.net/T/ But only keeps only his first patch. PATCH 2/2 reuses the work Clemens introduced in t/lib-httpd.sh back in 2008 to enable mod_dav_svn. The following

[PATCH 2/2] git svn: migrate tests to use lib-httpd

This allows us to use common test infrastructure and parallelize the tests. For now, GIT_SVN_TEST_HTTPD=true needs to be set to enable the SVN HTTP tests because we reuse the same test cases for both file:// and http:// SVN repositories. SVN_HTTPD_PORT is no longer honored. Tested under Apache

[PATCH 1/2] t/t91*: do not say how to avoid the tests

From: Michael J Gruber Some of the tests "say" how to stop the svn tests from running, some do not. The test suite is directed at people reading t/README where we keep all information about running the test suite (partly, with options etc.). Remove said "say"

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze: > From: Lars Schneider Nb. this line is only needed if you want author name and/or date different from the email sender, or if you have sender line misconfigured (e.g. lacking the human readable name). > >

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

Hi Lars, On 23/07/16 00:19, Ramsay Jones wrote: > > > On 22/07/16 16:49, larsxschnei...@gmail.com wrote: >> From: Lars Schneider >> >> Git's clean/smudge mechanism invokes an external filter process for every >> single blob that is affected by a filter. If Git

Re: git-prompt.sh incompatible with non-basic global grep.patternType

On Fri, Jul 22, 2016 at 3:21 PM, Junio C Hamano wrote: > Subject: [PATCH] grep: further simplify setting the pattern type > > When c5c31d33 (grep: move pattern-type bits support to top-level > grep.[ch], 2012-10-03) introduced grep_commit_pattern_type() helper > function, the

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 22/07/16 16:49, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Git's clean/smudge mechanism invokes an external filter process for every > single blob that is affected by a filter. If Git filters a lot of blobs > then the startup time of the external

[PATCH] format-patch: escape "From " lines recognized by mailsplit

Users have mistakenly copied "From " lines into commit messages in the past, and will certainly make the same mistakes in the future. Since not everyone uses mboxrd, yet, we should at least prevent miss-split mails by always escaping "From " lines based on the check used by mailsplit. mailsplit

Re: [PATCH v4 4/8] doc: give headings for the two and three dot notations

Philip Oakley writes: > +Special '{caret}' Shorthand Notations > +~~ > +Two other shorthands exist, particularly useful for merge commits, is > +for naming a set that is formed by a commit and its parent commits. As these are not all

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote: From: Lars Schneider Git's clean/smudge mechanism invokes an external filter process for every single blob that is affected by a filter. If Git filters a lot of blobs then the startup time of the external

Re: [PATCH/RFC] fast-import: Keep a fake pack window on the recently written data

Hi, Any thoughts on the following? Mike On Mon, Jul 04, 2016 at 08:44:39AM +0900, Mike Hommey wrote: > The are many ways in which fast-import ends up calling gfi_unpack_entry, > and fery few work-arounds. I've patched fast-import for it to be smarter > in corner cases, allowing some additional

Re: [PATCH v1 0/3] Git filter protocol

larsxschnei...@gmail.com writes: > The first two patches are cleanup patches which are not really necessary > for the feature. These two looked trivially good. I think I can agree with what 3/3 wants to do in principle, but * "protocol" is not quite the right word. The current way to

[PATCH] git-svn: allow --version to work anywhere

Junio C Hamano wrote: > Eric Wong writes: > > I'm hoping "cd /" in the test will always succeed; > > but I suppose non-*nix systems might fail, here. > > How about digging a few levels of directory hierarchy, exporting > GIT_CEILING_DIRECTORIES so that we

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Jeff King writes: > But even that is a lesser breakage than taking away grep.extendedRegexp > entirely. Taking it away breaks anybody who uses it; tweaking (2) only > breaks people who set both config variables. But why would anyone do > that? OK. Now we have an evidence that we

Re: [PATCH] Documentation: pack-protocol correct NAK response

On Fri, Jul 22, 2016 at 1:28 PM, Stefan Beller wrote: > In the transport protocol we use NAK to signal the non existence of a > common base, so fix the documentation. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

[PATCH] Documentation: pack-protocol correct NAK response

In the transport protocol we use NAK to signal the non existence of a common base, so fix the documentation. This helps readers of the document, as they don't have to wonder about the difference between NAK and NACK. As NACK is used in git archive and upload-archive, this is easy to get wrong.

Re: [PATCH] contrib/persistent-https: use Git version for build label

> We tend to avoid catting a single file only to pipe the result into a > different command You got it. Here's a new patch: >From 432c0054a28a6c91b9fc1d9b53714061cb3d903c Mon Sep 17 00:00:00 2001 From: Parker Moore Date: Wed, 20 Jul 2016 18:33:28 -0600 Subject: [PATCH]

Re: git-prompt.sh incompatible with non-basic global grep.patternType

On Fri, Jul 22, 2016 at 12:51:00PM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> This comes from b22520a3 (grep: allow -E and -n to be turned on by > >> default via configuration, 2011-03-30) back when we didn't have a > >> more generic grep.patternType configuration

Re: [PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

On Fri, Jul 22, 2016 at 12:52 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> The approach to tests is different though. I like yours better than mine, >> as it doesn't add more tests, but strengthens existing tests. > > So... are you retracting >

Re: [PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

Stefan Beller writes: >> I expect I'd queue these two instead, after seeing Acks from Stefan. >> >> Thanks. > > Sure. Please take these 2 patches instead of mine. OK, I've already queued yours but I haven't started today's integration cycle yet (I first pick up new topics

[PATCH v2 3/6] doc/pretty-formats: describe index/time formats for %gd

The "reflog selector" format changes based on a series of heuristics, and that applies equally to both stock "log -g" output, as well as "--format=%gd". The documentation for "%gd" doesn't cover this. Let's mention the multiple formats and refer the user back to the "-g" section for the complete

[PATCH v2 4/6] doc/pretty-formats: explain shortening of %gd

The actual shortening rules aren't that interesting and probably not worth getting into (I gloss over them here as "shortened for human readability"). But the fact that %gD shows whatever you gave on the command line is subtle and worth mentioning. Since most people will feed a shortened refname

Re: [PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

Stefan Beller writes: > The approach to tests is different though. I like yours better than mine, > as it doesn't add more tests, but strengthens existing tests. So... are you retracting http://thread.gmane.org/gmane.comp.version-control.git/25 and instead giving an Ack

[PATCH v2 6/6] date: add "unix" format

We already have "--date=raw", which is a Unix epoch timestamp plus a contextual timezone (either the author's or the local). But one may not care about the timezone and just want the epoch timestamp by itself. It's not hard to parse the two apart, but if you are using a pretty-print format, you

[PATCH v2 5/6] date: document and test "raw-local" mode

The "raw" format shows a Unix epoch timestamp, but with a timezone tacked on. The timestamp is not _in_ that zone, but it is extra information about the time (by default, the zone the author was in). The documentation claims that "raw-local" does not work. It does, but the end result is rather

[PATCH v2 2/6] doc/rev-list-options: explain "-g" output formats

We document that asking for HEAD@{now} will switch the output to show HEAD@{timestamp}, but not that specifying `--date` has a similar effect, or that it can be overridden with HEAD@{0}. Let's do so. These rules come from 794151e (reflog-walk: always make HEAD@{0} show indexed selectors,

[PATCH v2 1/6] doc/rev-list-options: clarify "commit@{Nth}" for "-g" option

When "log -g" shows "HEAD@{1}", "HEAD@{2}", etc, calling that "commit@{Nth}" is not really accurate. The "HEAD" part is really the refname. By saying "commit", a reader may misunderstand that to mean something related to the specific commit we are showing, not the ref whose reflog we are

[PATCH v2 0/6] reflog docs and date-formatting

This is a repost of the patches in: http://thread.gmane.org/gmane.comp.version-control.git/299201/focus=299236 since I don't think they got picked up at all. The contents are the same, but with one extra patch (the 4th) that was posted mid-discussion. The only other review comment is that

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Jeff King writes: >> This comes from b22520a3 (grep: allow -E and -n to be turned on by >> default via configuration, 2011-03-30) back when we didn't have a >> more generic grep.patternType configuration mechanism in v1.7.5 >> days, and it probably need to be deprecated to

Re: [PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

On Fri, Jul 22, 2016 at 12:39 PM, Junio C Hamano wrote: > Johannes Sixt writes: > >> 'git submodule--helper update-clone' has logic to retry failed clones >> a second time. For this purpose, there is a list of submodules to clone, >> and a second list that is

Re: [PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

Johannes Sixt writes: > 'git submodule--helper update-clone' has logic to retry failed clones > a second time. For this purpose, there is a list of submodules to clone, > and a second list that is filled with the submodules to retry. Within > these lists, the submodules are

Re: [PATCH ew/daemon-socket-keepalive] Windows: add missing definition of ENOTSOCK

Johannes Sixt wrote: > The previous commit introduced the first use of ENOTSOCK. This macro is > not available on Windows. Define it as WSAENOTSOCK because that is the > corresponding error value reported by the Windows versions of socket > functions. Thanks. I thought

Re: [PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

On Fri, Jul 22, 2016 at 12:15 PM, Johannes Sixt wrote: > 'git submodule--helper update-clone' has logic to retry failed clones > a second time. For this purpose, there is a list of submodules to clone, > and a second list that is filled with the submodules to retry. Within > these

Re: [PATCH] diff: do not reuse worktree files that need "clean" conversion

Jeff King writes: > So I think we actually _can_ think of would_convert_to_git() as > basically free. Or as free as other efficient-lookup functions we call > like cache_name_pos(). OK. > The thought "does this tree reuse even speed things up enough to justify > its complexity"

Re: [PATCH ew/daemon-socket-keepalive] Windows: add missing definition of ENOTSOCK

Johannes Schindelin writes: > Hi Hannes, > > On Thu, 21 Jul 2016, Johannes Sixt wrote: > >> The previous commit introduced the first use of ENOTSOCK. This macro is >> not available on Windows. Define it as WSAENOTSOCK because that is the >> corresponding error value

Re: git-prompt.sh incompatible with non-basic global grep.patternType

On Fri, Jul 22, 2016 at 12:21:31PM -0700, Junio C Hamano wrote: > One thing that I noticed is that there is this strange field > in grep_opt called .extended_regexp_option; it only is set from the > boolean configuration grep.extendedregexp and worse yet it takes > precedence over the command

Re: [PATCH 1/2] git-submodule: forward exit code of git-submodule--helper more faithfully

On Fri, Jul 22, 2016 at 12:14 PM, Johannes Sixt wrote: > git-submodule--helper is invoked as the upstream of a pipe in several > places. Usually, the failure of a program in this position is not > detected by the shell. For this reason, the code inserts a token in the > output

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Jeff King writes: > I gave a very cursory look when I wrote the other email, and your > alternative solution is what looked like the most elegant fix to me. > > I suspect this bug has been there quite a while, so no rush. :) Here is what I am going to queue. One thing that I

[PATCH 2/2] submodule-helper: fix indexing in clone retry error reporting path

'git submodule--helper update-clone' has logic to retry failed clones a second time. For this purpose, there is a list of submodules to clone, and a second list that is filled with the submodules to retry. Within these lists, the submodules are identified by an index as if both lists were just

[PATCH 1/2] git-submodule: forward exit code of git-submodule--helper more faithfully

git-submodule--helper is invoked as the upstream of a pipe in several places. Usually, the failure of a program in this position is not detected by the shell. For this reason, the code inserts a token in the output stream when git-submodule--helper fails that is detected downstream, where the

Re: [PATCH] diff: do not reuse worktree files that need "clean" conversion

On Fri, Jul 22, 2016 at 10:44:08AM -0700, Junio C Hamano wrote: > > diff --git a/diff.c b/diff.c > > index 7d03419..b43d3dd 100644 > > --- a/diff.c > > +++ b/diff.c > > @@ -2683,6 +2683,13 @@ static int reuse_worktree_file(const char *name, > > const unsigned char *sha1, int > > if

Re: [PATCH] contrib/persistent-https: use Git version for build label

Parker Moore writes: > diff --git a/contrib/persistent-https/Makefile > b/contrib/persistent-https/Makefile > index 92baa3be..8248269 100644 > --- a/contrib/persistent-https/Makefile > +++ b/contrib/persistent-https/Makefile > @@ -12,7 +12,7 @@ > # See the License for the

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

Parker Moore writes: > From: Parker Moore > > This fixes contrib/persistent-https builds for Go v1.7+ and is > compatible with Go v1.0+. Thanks, applied. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [PATCH] diff: do not reuse worktree files that need "clean" conversion

Jeff King writes: > Subject: diff: do not reuse worktree files that need "clean" conversion > > When accessing a blob for a diff, we may try to reuse file > contents in the working tree, under the theory that it is > faster to mmap those file contents than it would be to > extract

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Fri, Jul 22, 2016 at 7:25 PM, Stefan Beller wrote: > On Fri, Jul 22, 2016 at 10:09 AM, Duy Nguyen wrote: >> >> I just quickly glanced through the rest of this mail because, as a >> submodule ignorant, it's just mumbo jumbo to me. But what I see here >>

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> From a users POV there are: >> * non existent submodules (no gitlink recorded, no config set, >> no repo in place) >> * not initialized submodules (gitlink is recorded, no

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Fri, Jul 22, 2016 at 10:09 AM, Duy Nguyen wrote: > > I just quickly glanced through the rest of this mail because, as a > submodule ignorant, it's just mumbo jumbo to me. But what I see here > is, there may be problems if we choose to share some submodule info, > but I

Re: [RFC/PATCH] status: suggest 'git merge --abort' when appropriate

Matthieu Moy writes: > We already suggest 'git rebase --abort' during a conflicted rebase. > Similarly, suggest 'git merge --abort' during conflict resolution on > 'git merge'. > > Signed-off-by: Matthieu Moy > --- It wasn't immediately obvious

Re: [PATCH] git-subtree.sh: Use --allow-unrelated-histories when splitting with --rejoin

On 22 July 2016 at 01:11, Johannes Schindelin wrote: > I know it feels good to get frustration off of your chest by ranting. I am > very sympathetic to that. Please note, however, that it puts the people > who are ready to help you immediately into a defensive corner.

Re: [PATCH v4 2/4] submodule: update core.worktree using git-config

On Thu, Jul 21, 2016 at 12:04 AM, Stefan Beller wrote: >> diff --git a/submodule.c b/submodule.c >> index abc2ac2..b912871 100644 >> --- a/submodule.c >> +++ b/submodule.c >> @@ -1128,7 +1128,9 @@ void connect_work_tree_and_git_dir(const char >> *work_tree, const char

Re: [RFC] git-svn: allow --version to work anywhere

Eric Wong writes: > Checking the version of the installed SVN libraries should not > require a git repository at all. This matches the behavior of > "git --version". > > Add a test for "git svn help" for the same behavior while we're > at it, too. > > Signed-off-by: Eric Wong

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Thu, Jul 21, 2016 at 1:22 AM, Stefan Beller wrote: > On Wed, Jul 20, 2016 at 10:24 AM, Nguyễn Thái Ngọc Duy > wrote: >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- >> Documentation/git-worktree.txt | 8 >> git-submodule.sh

Re: [PATCH v1 3/6] Per-file output for Porcelain Status V2

Jeff Hostetler writes: >>> + case DIFF_STATUS_DELETED: >>> + d->porcelain_v2.mode_index = p->one->mode; >>> + hashcpy(d->porcelain_v2.sha1_index, p->one->sha1); >>> + break; >>> + >>> + case DIFF_STATUS_COPIED: >>> + case

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

Stefan Beller writes: > From a users POV there are: > * non existent submodules (no gitlink recorded, no config set, > no repo in place) > * not initialized submodules (gitlink is recorded, no config set, > and an empty repo is put in the working tree as a place holder).

[PATCH v2 2/3] contrib/git-jump: add whitespace-checking mode

On Fri, Jul 22, 2016 at 12:29:45PM -0400, Jeff King wrote: > If you have whitespace errors in lines you've introduced, it > can be convenient to be able to jump directly to them for > fixing. You can't quite use "git jump diff" for this, > because though it passes arbitrary options to "git

[PATCH 3/3] contrib/git-jump: fix typo in README

Signed-off-by: Jeff King --- contrib/git-jump/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/git-jump/README b/contrib/git-jump/README index 1cebc32..202b499 100644 --- a/contrib/git-jump/README +++ b/contrib/git-jump/README @@ -83,7 +83,7 @@

[PATCH 2/3] contrib/git-jump: add whitespace-checking mode

If you have whitespace errors in lines you've introduced, it can be convenient to be able to jump directly to them for fixing. You can't quite use "git jump diff" for this, because though it passes arbitrary options to "git diff", it expects to see an actual unified diff in the output. Whereas

[PATCH 1/3] contrib/git-jump: fix greedy regex when matching hunks

The hunk-header regex looks for "\+\d+" to find the post-image line numbers, but it skips the pre-image line numbers with a simple ".*". That means we may greedily eat the post-image numbers and match a "\+\d" further on, in the funcname text. For example, commit 6b9c38e has this hunk header:

[PATCH 0/3] minor git-jump improvements

Here are a few quick fixes and features for git-jump. The first is a bug I noticed and fixed recently. And that reminded me of the second one, which I'd been carrying in my local copy for a long time. [1/3]: contrib/git-jump: fix greedy regex when matching hunks [2/3]: contrib/git-jump: add

Re: [PATCH] use strbuf_addbuf() for appending a strbuf to another

Jeff King writes: > I don't think we do. Going back to the original discussion: > > http://thread.gmane.org/gmane.comp.version-control.git/136141/focus=136774 > > it was mostly just "hey, this would fail really confusingly if we ever > did, so let's make it safe". > > The second

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

On Fri, Jul 22, 2016 at 12:32 AM, Jens Lehmann wrote: > Am 21.07.2016 um 01:22 schrieb Stefan Beller: >> >> So maybe we want to drop that series and first talk about a migration plan >> from >> the current state to a world where we have the existence depending not >> on the

Re: Git and SHA-1 security (again)

Johannes Schindelin writes: > Hi Junio, > > On Mon, 18 Jul 2016, Junio C Hamano wrote: > >> "brian m. carlson" writes: >> >> > I will say that the pack format will likely require some changes, >> > because it assumes ... The reason is

Re: What's cooking in git.git (Jul 2016, #06; Tue, 19)

Pranit Bauva writes: > The current branch contains 30-40 % of the work. I am going to send 3 > more functions check_and_set_terms(), bisect_next_check() and > bisect_terms() positively by today. After that the work will be around > 50-60% complete. After that

[PATCH v1 3/3] convert: add filter..useProtocol option

From: Lars Schneider Git's clean/smudge mechanism invokes an external filter process for every single blob that is affected by a filter. If Git filters a lot of blobs then the startup time of the external filter processes can become a significant part of the overall Git

[PATCH v1 2/3] convert: modernize tests

From: Lars Schneider Use `test_config` to set the config, check that files are empty with `test_must_be_empty`, compare files with `test_cmp`, and remove spaces after ">". Signed-off-by: Lars Schneider --- t/t0021-conversion.sh | 62

[PATCH v1 1/3] convert: quote filter names in error messages

From: Lars Schneider Git filter with spaces (e.g. `filter.sh foo`) are hard to read in error messages. Quote them to improve the readability. Signed-off-by: Lars Schneider --- convert.c | 12 ++-- 1 file changed, 6 insertions(+), 6

[PATCH v1 0/3] Git filter protocol

From: Lars Schneider Hi, Git's clean/smudge mechanism invokes an external filter process for every single blob that is affected by a filter. If Git filters a lot of blobs then the startup time of the external filter processes can become a significant part of the

[PATCH] diff: do not reuse worktree files that need "clean" conversion

On Thu, Jul 21, 2016 at 05:37:40PM -0400, Jeff King wrote: > The next three are to show the final diffstat after the commit > completes. It looks like the "should we reuse the worktree file?" > optimization in diff_populate_filespec() does not take into account > whether we will have to convert

Re: [PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

Hey Torsten, On Fri, Jul 22, 2016 at 7:59 AM, Torsten Bögershausen wrote: > > > On 07/20/2016 11:47 PM, Pranit Bauva wrote: >> >> Reimplement the `get_terms` and `bisect_terms` shell function in C and >> add `bisect-terms` subcommand to `git bisect--helper` to call it from >>

[PATCH v4 16/16] merge-recursive: flush output buffer even when erroring out

Ever since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we had a problem: When the merge failed in a fatal way, all regular output was swallowed because we called die() and did not get a chance to drain the output buffers. To fix this, several modifications were necessary:

[PATCH v4 13/16] merge-recursive: write the commit title in one go

In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we changed the code such that it prints the output in one go, to avoid interfering with the progress output. Let's make sure that the same holds true when outputting the commit title: previously, we used several printf()

[PATCH v4 14/16] merge-recursive: offer an option to retain the output in 'obuf'

Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we already accumulate the output in a buffer. The idea was to avoid interfering with the progress output that goes to stderr, which is unbuffered, when we write to stdout, which is buffered. We extend that buffering to allow

[PATCH v4 11/16] am -3: use merge_recursive() directly again

Last October, we had to change this code to run `git merge-recursive` in a child process: git-am wants to print some helpful advice when the merge failed, but the code in question was not prepared to return, it die()d instead. We are finally at a point when the code *is* prepared to return

[PATCH v4 12/16] merge-recursive: flush output buffer before printing error messages

The data structure passed to the recursive merge machinery has a feature where the caller can ask for the output to be buffered into a strbuf, by setting the field 'buffer_output'. Previously, we simply swallowed the buffered output when showing error messages. With this patch, we show the output

[PATCH v4 15/16] Ensure that the output buffer is released after calling merge_trees()

The recursive merge machinery accumulates its output in an output buffer, to be flushed at the end of merge_recursive(). At this point, we forgot to release the output buffer. When calling merge_trees() (i.e. the non-recursive part of the recursive merge) directly, the output buffer is never

[PATCH v4 04/16] merge-recursive: clarify code in was_tracked()

It can be puzzling to see that was_tracked() asks to get an index entry by name, but does not take a negative return value for an answer. The reason we have to do this is that cache_name_pos() only looks for entries in stage 0, even if nobody asked for any stage in particular. Let's rewrite the

[PATCH v4 02/16] Report bugs consistently

The vast majority of error messages in Git's source code which report a bug use the convention to prefix the message with "BUG:". As part of cleaning up merge-recursive to stop die()ing except in case of detected bugs, let's just make the remainder of the bug reports consistent with the de facto

[PATCH v4 10/16] merge-recursive: switch to returning errors instead of dying

The recursive merge machinery is supposed to be a library function, i.e. it should return an error when it fails. Originally the functions were part of the builtin "merge-recursive", though, where it was simpler to call die() and be done with error handling. The existing callers were already

[PATCH v4 09/16] merge-recursive: handle return values indicating errors

We are about to libify the recursive merge machinery, where we only die() in case of a bug or memory contention. To that end, we must heed negative return values as indicating errors. This requires our functions to be careful to pass through error conditions in call chains, and for quite a few

[PATCH v4 06/16] merge_recursive: abort properly upon errors

There are a couple of places where return values indicating errors are ignored. Let's teach them manners. Signed-off-by: Johannes Schindelin --- merge-recursive.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/merge-recursive.c

[PATCH v4 03/16] Avoid translating bug messages

While working on the patch series that avoids die()ing in recursive merges, the issue came up that bug reports (i.e. die("BUG: ...") constructs) should never be translated, as the target audience is the Git developer community, not necessarily the current user, and hence a translated message would

[PATCH v4 01/16] Verify that `git pull --rebase` shows the helpful advice when failing

It was noticed by Brendan Forster last October that the builtin `git am` regressed on that. Our hot fix reverted to spawning the recursive merge instead of using it as a library function. As we are about to revert that hot fix, after making the recursive merge a true library function (i.e. a

[PATCH v4 07/16] merge-recursive: avoid returning a wholesale struct

It is technically allowed, as per C89, for functions' return type to be complete structs (i.e. *not* just pointers to structs). However, it was just an oversight of this developer when converting Python code to C code in 6d297f8 (Status update on merge-recursive in C, 2006-07-08) which introduced

[PATCH v4 08/16] merge-recursive: allow write_tree_from_memory() to error out

It is possible that a tree cannot be written (think: disk full). We will want to give the caller a chance to clean up instead of letting the program die() in such a case. Signed-off-by: Johannes Schindelin --- merge-recursive.c | 4 ++-- 1 file changed, 2

[PATCH v4 05/16] Prepare the builtins for a libified merge_recursive()

Previously, callers of merge_trees() or merge_recursive() expected that code to die() with an error message. This used to be okay because we called those commands from scripts, and had a chance to print out a message in case the command failed fatally (read: with exit code 128). As scripting

[PATCH v4 00/16] Use merge_recursive() directly in the builtin am

This is the fourth iteration of the long-awaited re-roll of the attempt to avoid spawning merge-recursive from the builtin am and use merge_recursive() directly instead. The *real* reason for the reroll is that I need a libified recursive merge to accelerate the interactive rebase by teaching the

Investment Funds

Good Day, I am Miss Evelyn Kouassi. I will like to invest in your country. I have a Mutual business proposal which will benefit both of us. I will like to seek your consent first. This project involves a huge specific amount which I can't mention here for security reasons. If you feel you can

Re: [PATCH ew/daemon-socket-keepalive] Windows: add missing definition of ENOTSOCK

Hi Hannes, On Thu, 21 Jul 2016, Johannes Sixt wrote: > The previous commit introduced the first use of ENOTSOCK. This macro is > not available on Windows. Define it as WSAENOTSOCK because that is the > corresponding error value reported by the Windows versions of socket > functions. Thanks for

Re: [PATCH] git-subtree.sh: Use --allow-unrelated-histories when splitting with --rejoin

Hi Brett, On Thu, 21 Jul 2016, Brett Cundal wrote: > [re-sending as plain-text so the list software doesn't reject as > spam... what decade is this?] I know it feels good to get frustration off of your chest by ranting. I am very sympathetic to that. Please note, however, that it puts the

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

Am 21.07.2016 um 01:22 schrieb Stefan Beller: So maybe we want to drop that series and first talk about a migration plan from the current state to a world where we have the existence depending not on the url parameter, but a boolean variable submodule... Depending on a submodule would be