git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Adam Dinwoodie <adam@dinwoodie.org>
Cc: Bryan Turner <bturner@atlassian.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Bug using `fetch` with blank `-c` arguments to git
Date: Fri, 7 Jan 2022 13:52:20 +0100	[thread overview]
Message-ID: <Ydg3hE+ZcCq4qW9m@ncase> (raw)
In-Reply-To: <CA+kUOam-Dd-XUk0XaOfw4_rUTg=Ws7w5H=vZ=ZZeEo4XJfsVOg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3965 bytes --]

On Tue, Jan 04, 2022 at 09:00:45PM +0000, Adam Dinwoodie wrote:
> On Tue, 4 Jan 2022 at 20:04, Bryan Turner <bturner@atlassian.com> wrote:
> >
> > On Tue, Jan 4, 2022 at 4:37 AM Adam Dinwoodie <adam@dinwoodie.org> wrote:
> > >
> > > While investigating some issues with a different project, I discovered
> > > the command `git -c config.helper= fetch` was working with the Debian
> > > stable version of Git (v2.30.2) but not with my local build
> > > (v2.34.1.428.gdcc0cd074f).
> >
> > Since you're working with a locally-built Git, have you, by chance,
> > actually _installed_ that build, or is it simply in the Git repository
> > itself after running make?
> >
> > If you haven't _installed_ your build, my guess is you might be
> > getting a mismatch wherein your _built_ Git, when it forks out
> > subprocesses, is triggering your _installed_ Git (which I assume you
> > have, and which I assume is not 2.34.1). Git compiles paths into
> > itself to know where to find certain binaries, and if you run a
> > compiled-but-not-installed Git then those paths are "wrong". (I see
> > administrators do this fairly often when building Git from source to
> > set up Bitbucket Server.)
> >
> > What does `./git --exec-path` print, when you run your 2.34.1 binary?
> > And is that where, for example, the compiled 2.34.1 versions of things
> > like `git-remote-https` are?
> 
> Good thoughts, but I initially hit this problem after having installed
> it; I reproduced it running Git from the working copy for ease of
> bisecting, but the problem definitely occurs using the compiled
> version after installation. The below was collected after running
> `make install` (plus all the previously noted build commands,
> including running the configure script to specify the installation
> path) with the commit I identified as introducing the problem:
> 
> ```
> $ type git
> git is hashed (/home/adam/.local/bin/git)
> 
> $ which git
> /home/adam/.local/bin/git
> 
> $ git --version
> git version 2.29.2.372.g1ff21c05ba
> 
> $ git --exec-path
> /home/adam/.local/libexec/git-core
> 
> $ ls $(git --exec-path)/git $(git --exec-path)/git-remote-https
> /home/adam/.local/libexec/git-core/git
> /home/adam/.local/libexec/git-core/git-remote-https
> 
> $ $(git --exec-path)/git --version
> git version 2.29.2.372.g1ff21c05ba
> 
> $ rm -rf tmp && git -c core.autocrlf=true clone git://github.com/git/git tmp
> Cloning into 'tmp'...
> error: bogus format in GIT_CONFIG_PARAMETERS
> fatal: unable to parse command-line config
> ```
> 
> For the sake of double-checking, though, I just uninstalled the
> version of Git in /usr/bin (after spending some time working out how
> to do that with apt, without also uninstalling dependencies I wanted
> to leave alone) and repeated the above commands, and got exactly the
> same output.

I cannot really reproduce this locally. But given that it happens on
some installations while it works alright on others my best guess is
that you're effectively running a "mixed" setup, where Git binaries of
one version execute Git binaries of a different version. The result
would be that they have different ways to encode GIT_CONFIG_PARAMETERS,
where new versions use the more robust, quoted format, which older
versions don't understand, or the other way round.

If my theory is correct, then I'm a bit on the edge to call this a bug.
Git expects its binaries to all be of the same version, so running such
a mixed setup is only going to cause problems. This isn't only true for
internal variables like the one we have here, but we also introduce new
command line switches and expect Git helpers to understand them without
any fallback if an old binary was executed.

You may want to verify that the Git executables you have are indeed able
to execute the correct auxiliary binaries as expected and that they all
stem from the same Git version.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-01-07 12:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 12:36 Bug using `fetch` with blank `-c` arguments to git Adam Dinwoodie
2022-01-04 15:35 ` Erik Cervin Edin
2022-01-04 16:15   ` Adam Dinwoodie
2022-01-04 16:30     ` Erik Cervin Edin
2022-01-04 20:04 ` Bryan Turner
2022-01-04 21:00   ` Adam Dinwoodie
2022-01-06 10:11     ` Adam Dinwoodie
2022-01-07 12:52     ` Patrick Steinhardt [this message]
2022-01-07 13:04       ` Adam Dinwoodie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ydg3hE+ZcCq4qW9m@ncase \
    --to=ps@pks.im \
    --cc=adam@dinwoodie.org \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).