git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH 0/4] git_connect: add some flexibility

From
Mike Hommey <mh@glandium.org>
Date
Apr 28, 2016, 23:29 UTC
Message-ID
<20160428232936.GA8663@glandium.org>
In-Reply-To
<xmqqbn4t637r.fsf@gitster.mtv.corp.google.com>
On Thu, Apr 28, 2016 at 10:41:12AM -0700, Junio C Hamano wrote:
Show 20 quoted lines
> Mike Hommey <mh@glandium.org> writes:
> 
> > As you may be aware, I'm working on a git remote helper to access
> > mercurial repositories (https://github.com/glandium/git-cinnabar/).
> >
> > At the moment, a small part is written in C, relying on the git code
> > base, but eventually, there would be more C.
> >
> > As I want to get rid of the dependency on Mercurial itself, I'm planning
> > to implement the wire protocol parts in git-cinnabar.
> 
> While all of the above sounds like a good thing to do, what I do not
> understand is why you need to even touch git_connect() at all, and
> we certainly do *not* want you to touch it to make its external
> interface unnecessarily ugly and complex with features that are only
> necessary if it needs to talk to non-git services.
> 
> In other words, why can't this cinnabar thing live on the other side
> of transport API, just like Git transport itself does not know about
> cURL and HTTP when talking with https:// repositories?

It does live on the other side of transport API. The changes are not about git itself talking to mercurial servers. They are about a remote helper (git-cinnabar), using native code based on git core code, to talk to mercurial servers. Because I'd rather bend git_connect a little, if I can, than copy it (as well as parse_connect_url). Because I want to benefit from all tweaks it has (handling GIT_SSH/GIT_SSH_COMMAND properly, handling tortoiseplink/plink properly, handling IPv6 forms of the ssh url properly, ...)

Now, tweaking git_connect is one possible way to do what I want. Another
would be to make parse_connect_url non-static, and move the ssh command
line construction to a separate (non-static) function. Something with a
signature like:
  void prepare_ssh_command(struct argv_array **command,
                           const char *hostandport)

that would essentially do the part of git_connect that is in the if (protocol == PROTO_SSH) block (not sure how CONNECT_DIAG_URL would fit in this, though).

Thoughts?
Mike
Previous: Junio C HamanoNext: Mike Hommey
Message 8 of 15 in “git_connect: add some flexibility”
  1. 0/4 git_connect: add some flexibilityMike Hommey, Apr 28, 2016
  2. 1/4 git_connect: extend to take a pseudo format string for the program to runMike Hommey, Apr 28, 2016
  3. 2/4 git_connect: avoid quoting the path on the command line when it's not necessaryMike Hommey, Apr 28, 2016
  4. Stefan BellerApr 28, 2016
  5. 3/4 git_connect: allow a file descriptor to be allocated for stderrMike Hommey, Apr 28, 2016
  6. 4/4 git_connect: add a flag to consider the path part of ssh urls relativeMike Hommey, Apr 28, 2016
  7. Junio C HamanoApr 28, 2016
  8. Mike HommeyApr 28, 2016
  9. 1/3 connect: make parse_connect_url publicMike Hommey, Apr 29, 2016
  10. 2/3 connect: group CONNECT_DIAG_URL handling codeMike Hommey, Apr 29, 2016
  11. Junio C HamanoApr 29, 2016
  12. Junio C HamanoApr 29, 2016
  13. Torsten BögershausenApr 29, 2016
  14. 3/3 connect: move ssh command line preparation to a separate (public) functionMike Hommey, Apr 29, 2016
  15. Junio C HamanoApr 29, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.