[PATCH] t7610: clean up foo.* tmpdir

[resend; the original subject with foo.XX was bounced by vger for being too sexy] -- >8 -- Subject: [PATCH] t7610: clean up foo.XX tmpdir The lazy prereq for MKTEMP uses "mktemp -t" to see if mergetool's internal mktemp call will be able to run. But unlike the call inside mergetool, we

Re: trustExitCode doesn't apply to vimdiff mergetool

On Sat, Nov 26, 2016 at 09:44:36PM -0500, Dun Peal wrote: > I'm using vimdiff as my mergetool, and have the following lines in > ~/.gitconfig: > > [merge] > tool = vimdiff > [mergetool "vimdiff"] > trustExitCode = true > > > My understanding from the docs is that this sets >

[PATCH] common-main: stop munging argv[0] path

On Sat, Nov 26, 2016 at 06:51:11PM +0100, Mike Galbraith wrote: > > On the other hand, I am sympathetic that something used to work and now > > doesn't. It probably wouldn't be that hard to work around it. > > > > The reason for the behavior change is that one of the cmd_main() > > functions was

trustExitCode doesn't apply to vimdiff mergetool

I'm using vimdiff as my mergetool, and have the following lines in ~/.gitconfig: [merge] tool = vimdiff [mergetool "vimdiff"] trustExitCode = true My understanding from the docs is that this sets mergetool.vimdiff.trustExitCode to true, thereby concluding that a merge hasn't been

Re: git-daemon regression: 650c449250d7 common-main: call git_extract_argv0_path()

On Sat, 2016-11-26 at 12:09 -0500, Jeff King wrote: > On Sat, Nov 26, 2016 at 03:03:48PM +0100, Mike Galbraith wrote: > > > git-daemon went broke on me post v2.9.3 due to binaries being installed > > in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it > > up, as does ln -s

Re: git-daemon regression: 650c449250d7 common-main: call git_extract_argv0_path()

On Sat, Nov 26, 2016 at 03:03:48PM +0100, Mike Galbraith wrote: > git-daemon went broke on me post v2.9.3 due to binaries being installed > in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it > up, as does ln -s /usr/lib/git/git-daemon /usr/bin/git-daemon 'course, > but

Re: git-daemon regression: 650c449250d7 common-main: call git_extract_argv0_path()

Hi Mike, On Sat, 2016-11-26 at 15:03 +0100, Mike Galbraith wrote: > Greetings, > > git-daemon went broke on me post v2.9.3 due to binaries being installed > in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it > up, as does ln -s /usr/lib/git/git-daemon /usr/bin/git-daemon

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

On Sat, Nov 26, 2016 at 01:22:28PM +0100, Johannes Schindelin wrote: > In other words, GIT_CONFIG_PARAMETERS is *explicitly scrubbed* from the > environment when we run our tests (by the code block between the "before" > and the "after" statements in the diff above). Sorry if I wasn't clear. I

git-daemon regression: 650c449250d7 common-main: call git_extract_argv0_path()

Greetings, git-daemon went broke on me post v2.9.3 due to binaries being installed in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it up, as does ln -s /usr/lib/git/git-daemon /usr/bin/git-daemon 'course, but thought I should report it, since it used to work without that.

RE: [char-misc-next] mei: request async autosuspend at the end of enumeration

> > W dniu 25.11.2016 o 04:14, Jeff King pisze: > > On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > > > > Cc: # 4.4+ > > Looks like git send-email is not able to parse this address > correctly though this is suggested format by >

Re: [PATCH v2 2/2] Avoid a segmentation fault with renaming merges

Hi, On Sat, 26 Nov 2016, Johannes Schindelin wrote: > diff --git a/merge-recursive.c b/merge-recursive.c > index 9041c2f149..609061f58a 100644 > --- a/merge-recursive.c > +++ b/merge-recursive.c > @@ -235,6 +235,8 @@ static int add_cacheinfo(struct merge_options *o, > struct

[PATCH v2 2/2] Avoid a segmentation fault with renaming merges

Under very particular circumstances, merge-recursive's `add_cacheinfo()` function gets a `NULL` returned from `refresh_cache_entry()` without expecting it, and subsequently passes it to `add_cache_entry()` which consequently crashes. Let's not crash. This fixes

[PATCH v2 1/2] cherry-pick: demonstrate a segmentation fault

In https://github.com/git-for-windows/git/issues/952, a complicated scenario was described that leads to a segmentation fault in cherry-pick. It boils down to a certain code path involving a renamed file that is dirty, for which `refresh_cache_entry()` returns `NULL`, and that `NULL` not being

[PATCH v2 0/2] Fix segmentation fault with cherry-pick

The culprit is actually not cherry-pick, but a special code path that expects refresh_cache_entry() not to return NULL. And the fix is to teach it to handle NULL there. This bug was brought to my attention by Markus Klein via https://github.com/git-for-windows/git/issues/952. Changes since v1:

Re: [PATCH 1/2] cherry-pick: demonstrate a segmentation fault

Hi, On Fri, 25 Nov 2016, Johannes Schindelin wrote: > +test_expect_failure 'cherry-pick fails gracefully with dirty renamed file' ' Woops. This title is wrong. It should say instead: 'cherry-pick succeeds with unrelated renamed, dirty file'. > + test_commit to-rename && > + git

Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin

Hi Peff, On Fri, 25 Nov 2016, Jeff King wrote: > On Fri, Nov 25, 2016 at 06:41:23PM +0100, Johannes Schindelin wrote: > > > > Ah, I didn't realize that was a requirement. If this is going to be part > > > of a release and real end-users are going to see it, that does make me > > > think the

Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)

On Thu, Nov 24, 2016 at 6:21 AM, Junio C Hamano wrote: > * nd/rebase-forget (2016-10-28) 1 commit > - rebase: add --forget to cleanup rebase, leave HEAD untouched > > "git rebase" learned "--forget" option, which allows a user to > remove the metadata left by an earlier "git