ing
> $HOME and git repositories being stores for my different configs)
That is solvable without needing multiple directories in
$GIT_EXEC_PATH. vcsh, which also solves the 'multiple repos with same
workdir' problem in a very thin wrapper around git, does this by
setting core.excludesfile in
Kevin Daudt writes:
> The commit that changed what you described is 1073094f3 (git-sh-setup:
> be explicit where to dot-source git-sh-i18n from., 2016-10-29). That
> commit claims there were already scripts that assumed GIT_EXEC_PATH is
> just a single entry. That commit was inclu
On Tue, Oct 17, 2017 at 06:21:22PM +0300, Nikolay Yakimov wrote:
> Hello. After updating to a recent git release (2.14, I believe, but
> possibly earlier), setting GIT_EXEC_PATH to multiple directories
> stopped working. It did work before, and I believe the culprit is
> 'git-sh-s
Hello. After updating to a recent git release (2.14, I believe, but
possibly earlier), setting GIT_EXEC_PATH to multiple directories
stopped working. It did work before, and I believe the culprit is
'git-sh-setup', which uses 'git --exec-path' output directly, while
most
On Tue, Apr 18, 2017 at 01:47:14PM +0200, Christoph Egger wrote:
> Hi!
>
> Concerning $GIT_EXEC_PATH .. is that supposed to be a $PATh like variable? as
> in can it have more than one path (colon-separated)? I have currently two
> directories there (one with a git-annex install
Hi!
Concerning $GIT_EXEC_PATH .. is that supposed to be a $PATh like variable? as
in can it have more than one path (colon-separated)? I have currently two
directories there (one with a git-annex installation, one with the normal git
stuff) and it seems to mostly work. However git-sh-setup is
Got it. Thanks!
On Thu, Mar 30, 2017 at 4:32 PM, Jeff King wrote:
> On Thu, Mar 30, 2017 at 04:00:41PM -0700, Nate Mueller wrote:
>
>> Really? My config has been set this way for years and it's never
>> caused problems before. I have subcommands in both of those
>> directories and all work.
>
On Thu, Mar 30, 2017 at 04:00:41PM -0700, Nate Mueller wrote:
> Really? My config has been set this way for years and it's never
> caused problems before. I have subcommands in both of those
> directories and all work.
Really. It did happen to work most of the time before (because most uses
inv
Really? My config has been set this way for years and it's never
caused problems before. I have subcommands in both of those
directories and all work.
On Thu, Mar 30, 2017 at 3:57 PM, Junio C Hamano wrote:
> Nate Mueller writes:
>
>> This fails for me because my GIT_EX
Nate Mueller writes:
> This fails for me because my GIT_EXEC_PATH is set to
> "/Library/Developer/CommandLineTools/usr/libexec/git-core:/Users/nate/.git-exec".
That environment variable is designed to hold a single path, not
like $PATH that lists multiple places in a colon separated list.
-sh-i18n"
This fails for me because my GIT_EXEC_PATH is set to
"/Library/Developer/CommandLineTools/usr/libexec/git-core:/Users/nate/.git-exec".
If I remove the second entry git-sh-setup works just fine.
Am I doing something wrong here? I can't see what but I'm surpris
"recently fixed" problems)
> commit c9bb5d101ca657fa466afa8c4368c43ea7b7aca8
> Author: Johannes Schindelin
> Date: Mon Jan 2 17:22:33 2017 +0100
>
> git_exec_path: avoid Coverity warning about unfree()d result
>
> Technically, it is correct that git_exec_p
2 17:22:33 2017 +0100
>
> git_exec_path: avoid Coverity warning about unfree()d result
>
> Technically, it is correct that git_exec_path() returns a possibly
> malloc()ed string returned from system_path(), and it is sometimes
> not allocated. Cache the result in a s
t think it's a big deal to do it on top, like this:
-- >8 --
Subject: git_exec_path: do not return the result of getenv()
The result of getenv() is not guaranteed by POSIX to last
beyond another call to getenv(), or setenv(), etc. We
should duplicate the string before returning to the caller
Stefan Beller writes:
> On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin
> wrote:
>> Technically, it is correct that git_exec_path() returns a possibly
>> malloc()ed string. Practically, it is *sometimes* not malloc()ed. So
>> let's just use a static variable to
On Tue, Jan 3, 2017 at 1:33 PM, Johannes Schindelin
wrote:
>
> This patch was originally only to appease Coverity, but it actually *does*
> plug a very real memory leak: previously, *every* call to git_exec_path()
> *possibly* returned a newly-malloc()ed buffer. Now, the first call
Hi Stefan,
On Tue, 3 Jan 2017, Stefan Beller wrote:
> On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin
> wrote:
> > Technically, it is correct that git_exec_path() returns a possibly
> > malloc()ed string. Practically, it is *sometimes* not malloc()ed. So
> > let'
On Tue, Jan 03, 2017 at 12:11:25PM -0800, Stefan Beller wrote:
> On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin
> wrote:
> > Technically, it is correct that git_exec_path() returns a possibly
> > malloc()ed string. Practically, it is *sometimes* not malloc()ed. So
&g
On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin
wrote:
> Technically, it is correct that git_exec_path() returns a possibly
> malloc()ed string. Practically, it is *sometimes* not malloc()ed. So
> let's just use a static variable to make it a singleton. That'll shut
>
Technically, it is correct that git_exec_path() returns a possibly
malloc()ed string. Practically, it is *sometimes* not malloc()ed. So
let's just use a static variable to make it a singleton. That'll shut
Coverity up, hopefully.
Signed-off-by: Johannes Schindelin
---
exec_cmd.c |
20 matches
Mail list logo
