git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
  2018-03-06 23:34 What's cooking in git.git (Mar 2018, #02; Tue, 6) Junio C Hamano
@ 2018-03-07 12:34 ` Johannes Schindelin
  2018-03-08  9:22   ` Ævar Arnfjörð Bjarmason
  2018-03-09  6:15 ` What's cooking in git.git (Mar 2018, #02; Tue, 6) Martin Ågren
  1 sibling, 1 reply; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-07 12:34 UTC (permalink / raw)
  To: Dan Jacques; +Cc: git, Junio C Hamano

Hi Dan,

On Tue, 6 Mar 2018, Junio C Hamano wrote:

> * dj/runtime-prefix (2017-12-05) 4 commits
>  . exec_cmd: RUNTIME_PREFIX on some POSIX systems
>  . Makefile: add Perl runtime prefix support
>  . Makefile: add support for "perllibdir"
>  . Makefile: generate Perl header from template file
> 
>  A build-time option has been added to allow Git to be told to refer
>  to its associated files relative to the main binary, in the same
>  way that has been possible on Windows for quite some time, for
>  Linux, BSDs and Darwin.
> 
>  Perhaps it is about time to reboot the effort?

You probably missed this in the huge "What's cooking" mail. Are you game?

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
  2018-03-07 12:34 ` Johannes Schindelin
@ 2018-03-08  9:22   ` Ævar Arnfjörð Bjarmason
  2018-03-08 13:12     ` Daniel Jacques
  0 siblings, 1 reply; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-08  9:22 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Dan Jacques, git, Junio C Hamano


On Wed, Mar 07 2018, Johannes Schindelin jotted:

> Hi Dan,
>
> On Tue, 6 Mar 2018, Junio C Hamano wrote:
>
>> * dj/runtime-prefix (2017-12-05) 4 commits
>>  . exec_cmd: RUNTIME_PREFIX on some POSIX systems
>>  . Makefile: add Perl runtime prefix support
>>  . Makefile: add support for "perllibdir"
>>  . Makefile: generate Perl header from template file
>>
>>  A build-time option has been added to allow Git to be told to refer
>>  to its associated files relative to the main binary, in the same
>>  way that has been possible on Windows for quite some time, for
>>  Linux, BSDs and Darwin.
>>
>>  Perhaps it is about time to reboot the effort?
>
> You probably missed this in the huge "What's cooking" mail. Are you game?

It would be great to have this rebooted now that my perl cleanup efforts
have un-blocked this. Will be happy to help review & test the next
iteration.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
  2018-03-08  9:22   ` Ævar Arnfjörð Bjarmason
@ 2018-03-08 13:12     ` Daniel Jacques
  2018-03-13 12:36       ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 28+ messages in thread
From: Daniel Jacques @ 2018-03-08 13:12 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Johannes Schindelin, git, Junio C Hamano

> It would be great to have this rebooted now that my perl cleanup efforts
> have un-blocked this. Will be happy to help review & test the next
> iteration.

Yes, I was just thinking the same thing. I wanted to make sure the Perl
changes had landed, and I'm pleased to see that they have. I should have
time in the next few days to rebase and put up a new version of the patch
series. I'll keep you in the loop, and thanks for pinging!

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
  2018-03-06 23:34 What's cooking in git.git (Mar 2018, #02; Tue, 6) Junio C Hamano
  2018-03-07 12:34 ` Johannes Schindelin
@ 2018-03-09  6:15 ` Martin Ågren
  2018-03-09  9:54   ` Duy Nguyen
  2018-03-09 17:19   ` Junio C Hamano
  1 sibling, 2 replies; 28+ messages in thread
From: Martin Ågren @ 2018-03-09  6:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

On 7 March 2018 at 00:34, Junio C Hamano <gitster@pobox.com> wrote:

> * ma/config-page-only-in-list-mode (2018-02-21) 3 commits
>  - config: change default of `pager.config` to "on"
>  - config: respect `pager.config` in list/get-mode only
>  - t7006: add tests for how git config paginates
>
>  In a way similar to how "git tag" learned to honor the pager
>  setting only in the list mode, "git config" learned to ignore the
>  pager setting when it is used for setting values (i.e. when the
>  purpose of the operation is not to "show").
>
>  Is this ready for 'next'?

I am not aware of any open questions or issues. You thought out loud
about how the series was structured, in particular about introducing a
successful test, then redefining it, as opposed to introducing it as a
failing test, then making it succeed. I hope I managed to motivate my
choice better in v2 (which is what you have picked up).

Duy wondered if it was sane to use a pager when we know that we are
"--get"-ing at most one config item. In v2, I addressed this by turning
on paging for a more careful selection of "--get"-ters.

Martin

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
  2018-03-09  6:15 ` What's cooking in git.git (Mar 2018, #02; Tue, 6) Martin Ågren
@ 2018-03-09  9:54   ` Duy Nguyen
  2018-03-09 17:19   ` Junio C Hamano
  1 sibling, 0 replies; 28+ messages in thread
From: Duy Nguyen @ 2018-03-09  9:54 UTC (permalink / raw)
  To: Martin Ågren; +Cc: Junio C Hamano, Git Mailing List

On Fri, Mar 9, 2018 at 1:15 PM, Martin Ågren <martin.agren@gmail.com> wrote:
> On 7 March 2018 at 00:34, Junio C Hamano <gitster@pobox.com> wrote:
>
>> * ma/config-page-only-in-list-mode (2018-02-21) 3 commits
>>  - config: change default of `pager.config` to "on"
>>  - config: respect `pager.config` in list/get-mode only
>>  - t7006: add tests for how git config paginates
>>
>>  In a way similar to how "git tag" learned to honor the pager
>>  setting only in the list mode, "git config" learned to ignore the
>>  pager setting when it is used for setting values (i.e. when the
>>  purpose of the operation is not to "show").
>>
>>  Is this ready for 'next'?
>
> I am not aware of any open questions or issues. You thought out loud
> about how the series was structured, in particular about introducing a
> successful test, then redefining it, as opposed to introducing it as a
> failing test, then making it succeed. I hope I managed to motivate my
> choice better in v2 (which is what you have picked up).
>
> Duy wondered if it was sane to use a pager when we know that we are
> "--get"-ing at most one config item. In v2, I addressed this by turning
> on paging for a more careful selection of "--get"-ters.

Yeah I got busy with stuff and didn't look at it. I've just checked
what's in 'pu'. Looks good to me.
-- 
Duy

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
  2018-03-09  6:15 ` What's cooking in git.git (Mar 2018, #02; Tue, 6) Martin Ågren
  2018-03-09  9:54   ` Duy Nguyen
@ 2018-03-09 17:19   ` Junio C Hamano
  1 sibling, 0 replies; 28+ messages in thread
From: Junio C Hamano @ 2018-03-09 17:19 UTC (permalink / raw)
  To: Martin Ågren; +Cc: Git Mailing List

Martin Ågren <martin.agren@gmail.com> writes:

>>  Is this ready for 'next'?
>
> I am not aware of any open questions or issues. You thought out loud
> about how the series was structured, in particular about introducing a
> successful test, then redefining it, as opposed to introducing it as a
> failing test, then making it succeed. I hope I managed to motivate my
> choice better in v2 (which is what you have picked up).
>
> Duy wondered if it was sane to use a pager when we know that we are
> "--get"-ing at most one config item. In v2, I addressed this by turning
> on paging for a more careful selection of "--get"-ters.

Yeah, I am aware of these exchanges, and they are resolved nicely, I
think.  I was mostly asking if other people have concerns we haven't
thought of yet.

Let's merge this to 'next', then.

Thanks.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-08 13:12     ` Daniel Jacques
@ 2018-03-13 12:36       ` Ævar Arnfjörð Bjarmason
  2018-03-13 18:36         ` Junio C Hamano
  2018-03-14 10:18         ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
  0 siblings, 2 replies; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-13 12:36 UTC (permalink / raw)
  To: Daniel Jacques; +Cc: Johannes Schindelin, git, Junio C Hamano


On Thu, Mar 08 2018, Daniel Jacques jotted:

>> It would be great to have this rebooted now that my perl cleanup efforts
>> have un-blocked this. Will be happy to help review & test the next
>> iteration.
>
> Yes, I was just thinking the same thing. I wanted to make sure the Perl
> changes had landed, and I'm pleased to see that they have. I should have
> time in the next few days to rebase and put up a new version of the patch
> series. I'll keep you in the loop, and thanks for pinging!

Related to this, I came across this bug report
https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is
wondering why we're installing N copies of the git binary, presumably
they're building with NO_INSTALL_HARDLINKS.

Just doing this:

    diff --git a/Makefile b/Makefile
    index de4b8f0c02..2222319a4f 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -2596,7 +2596,7 @@ endif
              for p in git$X $(filter $(install_bindir_programs),$(ALL_PROGRAMS)); do \
                    $(RM) "$$execdir/$$p" && \
                    test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
    -               ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
    +               ln -s "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
                    cp "$$bindir/$$p" "$$execdir/$$p" || exit; \
              done; \
            } && \

Seems to work for me, although obviously this would need to be optional,
and it'll get in the way of Daniel's patch since it use the absolute
path.

But is there any reason anyone can think of for why we shouldn't be
figuring out the relative path and symlinking the two?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-13 12:36       ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
@ 2018-03-13 18:36         ` Junio C Hamano
  2018-03-13 19:32           ` Randall S. Becker
                             ` (4 more replies)
  2018-03-14 10:18         ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
  1 sibling, 5 replies; 28+ messages in thread
From: Junio C Hamano @ 2018-03-13 18:36 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Daniel Jacques, Johannes Schindelin, git

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Related to this, I came across this bug report
> https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is
> wondering why we're installing N copies of the git binary, presumably
> they're building with NO_INSTALL_HARDLINKS.
> ...
> But is there any reason anyone can think of for why we shouldn't be
> figuring out the relative path and symlinking the two?


There is no fundamental reason not to offer such an "install" method
as an option; unless you count a more philosophical aversion to use
symlinks due to (perceived) additional fragility, that is.

The resulting code may become messier than without, but as long as
it is without the reasonable range for usual price we would pay for
a new "feature", that would be tolerable, I guess.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-13 18:36         ` Junio C Hamano
@ 2018-03-13 19:32           ` Randall S. Becker
  2018-03-13 20:39           ` [PATCH 0/3] Makefile: add a INSTALL_SYMLINKS option Ævar Arnfjörð Bjarmason
                             ` (3 subsequent siblings)
  4 siblings, 0 replies; 28+ messages in thread
From: Randall S. Becker @ 2018-03-13 19:32 UTC (permalink / raw)
  To: Junio C Hamano, Ævar Arnfjörð Bjarmason
  Cc: Daniel Jacques, Johannes Schindelin, git

On March 13, 2018 2:37 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > Related to this, I came across this bug report
> > https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is
> > wondering why we're installing N copies of the git binary, presumably
> > they're building with NO_INSTALL_HARDLINKS.
> > ...
> > But is there any reason anyone can think of for why we shouldn't be
> > figuring out the relative path and symlinking the two?
> 
> 
> There is no fundamental reason not to offer such an "install" method as an
> option; unless you count a more philosophical aversion to use symlinks due
> to (perceived) additional fragility, that is.
> 
> The resulting code may become messier than without, but as long as it is
> without the reasonable range for usual price we would pay for a new
> "feature", that would be tolerable, I guess.

A possible (remote) reason for not doing this is in environments using ACLs that somehow want different access permissions on some functions vs. others AND where the platform does not have the ability to separately secure links vs. objects. I don't know of such an environment, but you never know. I know it's a stretch, but I can see security-types being worried about this. I do know of environments where /usr/local/lib is secured differently from /usr/local/bin to prevent inappropriate .so loads on a selective basis, so there's that. Again, this is a stretch. As long as we continue to have a method of forcing the expensive way for the paranoidly inclined ;)    -- not meaning offence to those, of course.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.




^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH 0/3] Makefile: add a INSTALL_SYMLINKS option
  2018-03-13 18:36         ` Junio C Hamano
  2018-03-13 19:32           ` Randall S. Becker
@ 2018-03-13 20:39           ` Ævar Arnfjörð Bjarmason
  2018-03-13 20:39           ` [PATCH 1/3] Makefile: fix broken bindir_relative variable Ævar Arnfjörð Bjarmason
                             ` (2 subsequent siblings)
  4 siblings, 0 replies; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-13 20:39 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Daniel Jacques, Johannes Schindelin,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp,
	Ævar Arnfjörð Bjarmason

On Tue, Mar 13 2018, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Related to this, I came across this bug report
>> https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is
>> wondering why we're installing N copies of the git binary, presumably
>> they're building with NO_INSTALL_HARDLINKS.
>> ...
>> But is there any reason anyone can think of for why we shouldn't be
>> figuring out the relative path and symlinking the two?
>
>
> There is no fundamental reason not to offer such an "install" method
> as an option; unless you count a more philosophical aversion to use
> symlinks due to (perceived) additional fragility, that is.
>
> The resulting code may become messier than without, but as long as
> it is without the reasonable range for usual price we would pay for
> a new "feature", that would be tolerable, I guess.

Cool. I think it makes sense for us to have this. Here's an
implementation of it. The 3/3 patch looks a bit scary, but "git show"
with --word-diff will show that the change is minimal.

This steals a small piece from Daniel's relocatable series, and
doesn't in any way conflict with it. None of this will need to be
fixed up to make git relocatable since all the symlinks are relative
already.

Ævar Arnfjörð Bjarmason (3):
  Makefile: fix broken bindir_relative variable
  Makefile: add a gitexecdir_relative variable
  Makefile: optionally symlink libexec/git-core binaries to bin/git

 Makefile | 52 +++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 35 insertions(+), 17 deletions(-)

-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH 1/3] Makefile: fix broken bindir_relative variable
  2018-03-13 18:36         ` Junio C Hamano
  2018-03-13 19:32           ` Randall S. Becker
  2018-03-13 20:39           ` [PATCH 0/3] Makefile: add a INSTALL_SYMLINKS option Ævar Arnfjörð Bjarmason
@ 2018-03-13 20:39           ` Ævar Arnfjörð Bjarmason
  2018-03-13 20:39           ` [PATCH 2/3] Makefile: add a gitexecdir_relative variable Ævar Arnfjörð Bjarmason
  2018-03-13 20:39           ` [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git Ævar Arnfjörð Bjarmason
  4 siblings, 0 replies; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-13 20:39 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Daniel Jacques, Johannes Schindelin,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp,
	Ævar Arnfjörð Bjarmason

Change the bindir_relative variable to work like the other *_relative
variables, which are computed as a function of the absolute
path. Before this change, supplying e.g. bindir=/tmp/git/binaries to
the Makefile would yield a bindir_relative of just "bin", as opposed
to "binaries".

This logic was originally added back in 026fa0d5ad ("Move computation
of absolute paths from Makefile to runtime (in preparation for
RUNTIME_PREFIX)", 2009-01-18), then later in 971f85388f ("Makefile:
make mandir, htmldir and infodir absolute", 2013-02-24) when
more *_relative variables were added those new variables didn't have
this bug, but bindir_relative was never fixed.

There is a small change in behavior here, which is that setting
bindir_relative as an argument to the Makefile won't work anymore, I
think that's fine, since this was always intended as an internal
variable (e.g. INSTALL documents bindir=*, not bindir_relative=*).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index de4b8f0c02..b2f8f2b171 100644
--- a/Makefile
+++ b/Makefile
@@ -468,8 +468,7 @@ ARFLAGS = rcs
 # This can help installing the suite in a relocatable way.
 
 prefix = $(HOME)
-bindir_relative = bin
-bindir = $(prefix)/$(bindir_relative)
+bindir = $(prefix)/bin
 mandir = $(prefix)/share/man
 infodir = $(prefix)/share/info
 gitexecdir = libexec/git-core
@@ -486,6 +485,7 @@ lib = lib
 # DESTDIR =
 pathsep = :
 
+bindir_relative = $(patsubst $(prefix)/%,%,$(bindir))
 mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
 infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
 htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH 2/3] Makefile: add a gitexecdir_relative variable
  2018-03-13 18:36         ` Junio C Hamano
                             ` (2 preceding siblings ...)
  2018-03-13 20:39           ` [PATCH 1/3] Makefile: fix broken bindir_relative variable Ævar Arnfjörð Bjarmason
@ 2018-03-13 20:39           ` Ævar Arnfjörð Bjarmason
  2018-03-13 20:39           ` [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git Ævar Arnfjörð Bjarmason
  4 siblings, 0 replies; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-13 20:39 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Daniel Jacques, Johannes Schindelin,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp,
	Ævar Arnfjörð Bjarmason

This variable will be e.g. "libexec/git-core" if
gitexecdir=/tmp/git/libexec/git-core is given. It'll be used by a
subsequent change.

This is stolen from the yet-to-be integrated (needs resubmission)
"Makefile: add Perl runtime prefix support" patch on the mailing
list. See
<20180108030239.92036-3-dnj@google.com> (https://public-inbox.org/git/20180108030239.92036-3-dnj@google.com/).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index b2f8f2b171..ee0b6c8940 100644
--- a/Makefile
+++ b/Makefile
@@ -488,6 +488,7 @@ pathsep = :
 bindir_relative = $(patsubst $(prefix)/%,%,$(bindir))
 mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
 infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
+gitexecdir_relative = $(patsubst $(prefix)/%,%,$(gitexecdir))
 htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
 
 export prefix bindir sharedir sysconfdir gitwebdir perllibdir localedir
@@ -1735,6 +1736,7 @@ infodir_relative_SQ = $(subst ','\'',$(infodir_relative))
 perllibdir_SQ = $(subst ','\'',$(perllibdir))
 localedir_SQ = $(subst ','\'',$(localedir))
 gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
+gitexecdir_relative_SQ = $(subst ','\'',$(gitexecdir_relative))
 template_dir_SQ = $(subst ','\'',$(template_dir))
 htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
 prefix_SQ = $(subst ','\'',$(prefix))
-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-13 18:36         ` Junio C Hamano
                             ` (3 preceding siblings ...)
  2018-03-13 20:39           ` [PATCH 2/3] Makefile: add a gitexecdir_relative variable Ævar Arnfjörð Bjarmason
@ 2018-03-13 20:39           ` Ævar Arnfjörð Bjarmason
  2018-03-14  7:20             ` Johannes Sixt
  4 siblings, 1 reply; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-13 20:39 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Daniel Jacques, Johannes Schindelin,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp,
	Ævar Arnfjörð Bjarmason

Add a INSTALL_SYMLINKS option which if enabled, changes the default
hardlink installation method to one where the relevant binaries in
libexec/git-core are symlinked back to ../../bin, instead of being
hardlinked.

This new option also overrides the behavior of the existing
NO_*_HARDLINKS variables which in some cases would produce symlinks
within to libexec/, e.g. "git-add" symlinked to "git" which would be
copy of the "git" found in bin/, now "git-add" in libexec/ is always
going to be symlinked to the "git" found in the bin/ directory.

This option is being added because:

 1) I think it makes what we're doing a lot more obvious. E.g. I'd
    never noticed that the libexec binaries were really just hardlinks
    since e.g. ls(1) won't show that in any obvious way. You need to
    start stat(1)-ing things and look at the inodes to see what's
    going on.

 2) Some tools have very crappy support for hardlinks, e.g. the Git
    shipped with GitLab is much bigger than it should be because
    they're using a chef module that doesn't know about hardlinks, see
    https://github.com/chef/omnibus/issues/827

    I've also ran into other related issues that I think are explained
    by this, e.g. compiling git with debugging and rpm refusing to
    install a ~200MB git package with 2GB left on the FS, I think that
    was because it doesn't consider hardlinks, just the sum of the
    byte size of everything in the package.

As for the implementation, the "../../bin" noted above will vary given
some given some values of "../.." and "bin" depending on the depth of
the gitexecdir relative to the destdir, and the "bindir" target,
e.g. setting "bindir=/tmp/git/binaries gitexecdir=foo/bar/baz" will do
the right thing and produce this result:

    $ file /tmp/git/foo/bar/baz/git-add
    /tmp/git/foo/bar/baz/git-add: symbolic link to ../../../binaries/git

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Makefile | 46 +++++++++++++++++++++++++++++++---------------
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/Makefile b/Makefile
index ee0b6c8940..ac7616422d 100644
--- a/Makefile
+++ b/Makefile
@@ -329,6 +329,13 @@ all::
 # when hardlinking a file to another name and unlinking the original file right
 # away (some NTFS drivers seem to zero the contents in that scenario).
 #
+# Define INSTALL_SYMLINKS if you prefer to have everything that can be
+# symlinked between bin/ and libexec/ to use relative symlinks between
+# the two. This option overrides NO_CROSS_DIRECTORY_HARDLINKS and
+# NO_INSTALL_HARDLINKS which will also use symlinking by indirection
+# within the same directory in some cases, INSTALL_SYMLINKS will
+# always symlink to the final target directly.
+#
 # Define NO_CROSS_DIRECTORY_HARDLINKS if you plan to distribute the installed
 # programs as a tar, where bin/ and libexec/ might be on different file systems.
 #
@@ -2594,35 +2601,44 @@ endif
 
 	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
 	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
+	destdir_from_execdir_SQ=$$(echo '$(gitexecdir_relative_SQ)' | sed -e 's|[^/][^/]*|..|g') && \
 	{ test "$$bindir/" = "$$execdir/" || \
 	  for p in git$X $(filter $(install_bindir_programs),$(ALL_PROGRAMS)); do \
 		$(RM) "$$execdir/$$p" && \
-		test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
-		ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
-		cp "$$bindir/$$p" "$$execdir/$$p" || exit; \
+		test -n "$(INSTALL_SYMLINKS)" && \
+		ln -s "$$destdir_from_execdir_SQ/$(bindir_relative_SQ)/$$p" "$$execdir/$$p" || \
+		{ test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
+		  ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
+		  cp "$$bindir/$$p" "$$execdir/$$p" || exit; } \
 	  done; \
 	} && \
 	for p in $(filter $(install_bindir_programs),$(BUILT_INS)); do \
 		$(RM) "$$bindir/$$p" && \
-		test -z "$(NO_INSTALL_HARDLINKS)" && \
-		ln "$$bindir/git$X" "$$bindir/$$p" 2>/dev/null || \
-		ln -s "git$X" "$$bindir/$$p" 2>/dev/null || \
-		cp "$$bindir/git$X" "$$bindir/$$p" || exit; \
+		test -n "$(INSTALL_SYMLINKS)" && \
+		ln -s "git$X" "$$bindir/$$p" || \
+		{ test -z "$(NO_INSTALL_HARDLINKS)" && \
+		  ln "$$bindir/git$X" "$$bindir/$$p" 2>/dev/null || \
+		  ln -s "git$X" "$$bindir/$$p" 2>/dev/null || \
+		  cp "$$bindir/git$X" "$$bindir/$$p" || exit; } \
 	done && \
 	for p in $(BUILT_INS); do \
 		$(RM) "$$execdir/$$p" && \
-		test -z "$(NO_INSTALL_HARDLINKS)" && \
-		ln "$$execdir/git$X" "$$execdir/$$p" 2>/dev/null || \
-		ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
-		cp "$$execdir/git$X" "$$execdir/$$p" || exit; \
+		test -n "$(INSTALL_SYMLINKS)" && \
+		ln -s "$$destdir_from_execdir_SQ/$(bindir_relative_SQ)/git$X" "$$execdir/$$p" || \
+		{ test -z "$(NO_INSTALL_HARDLINKS)" && \
+		  ln "$$execdir/git$X" "$$execdir/$$p" 2>/dev/null || \
+		  ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
+		  cp "$$execdir/git$X" "$$execdir/$$p" || exit; } \
 	done && \
 	remote_curl_aliases="$(REMOTE_CURL_ALIASES)" && \
 	for p in $$remote_curl_aliases; do \
 		$(RM) "$$execdir/$$p" && \
-		test -z "$(NO_INSTALL_HARDLINKS)" && \
-		ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
-		ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
-		cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
+		test -n "$(INSTALL_SYMLINKS)" && \
+		ln -s "git-remote-http$X" "$$execdir/$$p" || \
+		{ test -z "$(NO_INSTALL_HARDLINKS)" && \
+		  ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+		  ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+		  cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; } \
 	done && \
 	./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
 
-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-13 20:39           ` [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git Ævar Arnfjörð Bjarmason
@ 2018-03-14  7:20             ` Johannes Sixt
  2018-03-14 10:14               ` Ævar Arnfjörð Bjarmason
  2018-03-15 17:03               ` Johannes Schindelin
  0 siblings, 2 replies; 28+ messages in thread
From: Johannes Sixt @ 2018-03-14  7:20 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: git, Junio C Hamano, Daniel Jacques, Johannes Schindelin,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp

Am 13.03.2018 um 21:39 schrieb Ævar Arnfjörð Bjarmason:
> Add a INSTALL_SYMLINKS option which if enabled, changes the default
> hardlink installation method to one where the relevant binaries in
> libexec/git-core are symlinked back to ../../bin, instead of being
> hardlinked.
> 
> This new option also overrides the behavior of the existing
> NO_*_HARDLINKS variables which in some cases would produce symlinks
> within to libexec/, e.g. "git-add" symlinked to "git" which would be
> copy of the "git" found in bin/, now "git-add" in libexec/ is always
> going to be symlinked to the "git" found in the bin/ directory.

It is important to leave the default at hard-linking the binaries, 
because on Windows symbolic links are second class citizens (they 
require special privileges and there is a distinction between link 
targets being files or directories). Hard links work well.

> 
> This option is being added because:
> 
>   1) I think it makes what we're doing a lot more obvious. E.g. I'd
>      never noticed that the libexec binaries were really just hardlinks
>      since e.g. ls(1) won't show that in any obvious way. You need to
>      start stat(1)-ing things and look at the inodes to see what's
>      going on.
> 
>   2) Some tools have very crappy support for hardlinks, e.g. the Git
>      shipped with GitLab is much bigger than it should be because
>      they're using a chef module that doesn't know about hardlinks, see
>      https://github.com/chef/omnibus/issues/827
> 
>      I've also ran into other related issues that I think are explained

s/ran/run/

>      by this, e.g. compiling git with debugging and rpm refusing to
>      install a ~200MB git package with 2GB left on the FS, I think that
>      was because it doesn't consider hardlinks, just the sum of the
>      byte size of everything in the package.
> 
> As for the implementation, the "../../bin" noted above will vary given
> some given some values of "../.." and "bin" depending on the depth of

s/given some//

> the gitexecdir relative to the destdir, and the "bindir" target,
> e.g. setting "bindir=/tmp/git/binaries gitexecdir=foo/bar/baz" will do
> the right thing and produce this result:
> 
>      $ file /tmp/git/foo/bar/baz/git-add
>      /tmp/git/foo/bar/baz/git-add: symbolic link to ../../../binaries/git
> 
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>   Makefile | 46 +++++++++++++++++++++++++++++++---------------
>   1 file changed, 31 insertions(+), 15 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index ee0b6c8940..ac7616422d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -329,6 +329,13 @@ all::
>   # when hardlinking a file to another name and unlinking the original file right
>   # away (some NTFS drivers seem to zero the contents in that scenario).
>   #
> +# Define INSTALL_SYMLINKS if you prefer to have everything that can be
> +# symlinked between bin/ and libexec/ to use relative symlinks between
> +# the two. This option overrides NO_CROSS_DIRECTORY_HARDLINKS and

s/ between the two//

> +# NO_INSTALL_HARDLINKS which will also use symlinking by indirection
> +# within the same directory in some cases, INSTALL_SYMLINKS will
> +# always symlink to the final target directly.

"the final target"? Do you mean "the git executable installed in 
$bindir" or something like this?

> +#
>   # Define NO_CROSS_DIRECTORY_HARDLINKS if you plan to distribute the installed
>   # programs as a tar, where bin/ and libexec/ might be on different file systems.
>   #
> @@ -2594,35 +2601,44 @@ endif
>   
>   	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
>   	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
> +	destdir_from_execdir_SQ=$$(echo '$(gitexecdir_relative_SQ)' | sed -e 's|[^/][^/]*|..|g') && \
>   	{ test "$$bindir/" = "$$execdir/" || \
>   	  for p in git$X $(filter $(install_bindir_programs),$(ALL_PROGRAMS)); do \
>   		$(RM) "$$execdir/$$p" && \
> -		test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
> -		ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
> -		cp "$$bindir/$$p" "$$execdir/$$p" || exit; \
> +		test -n "$(INSTALL_SYMLINKS)" && \
> +		ln -s "$$destdir_from_execdir_SQ/$(bindir_relative_SQ)/$$p" "$$execdir/$$p" || \
> +		{ test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
> +		  ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
> +		  cp "$$bindir/$$p" "$$execdir/$$p" || exit; } \

I think that it is unnecessary to place the later options in {} brackets 
because && and || have equal precedence in shell scripts. That is:

	want symlinks? &&
	make symlinks ||
	want hard links? &&
	make hard links ||
	make copies ||
	exit

Of course, it means that when symlinking fails, it falls back to hard 
links (if permitted) or copies, whichever works. But that also happens 
with your version.

(Ditto in the rest of the hunk, which I don't repeat here.)

-- Hannes

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-14  7:20             ` Johannes Sixt
@ 2018-03-14 10:14               ` Ævar Arnfjörð Bjarmason
  2018-03-14 17:21                 ` Linus Torvalds
  2018-03-15 17:03               ` Johannes Schindelin
  1 sibling, 1 reply; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-14 10:14 UTC (permalink / raw)
  To: Johannes Sixt
  Cc: git, Junio C Hamano, Daniel Jacques, Johannes Schindelin,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp


On Wed, Mar 14 2018, Johannes Sixt jotted:

> Am 13.03.2018 um 21:39 schrieb Ævar Arnfjörð Bjarmason:
>> Add a INSTALL_SYMLINKS option which if enabled, changes the default
>> hardlink installation method to one where the relevant binaries in
>> libexec/git-core are symlinked back to ../../bin, instead of being
>> hardlinked.
>>
>> This new option also overrides the behavior of the existing
>> NO_*_HARDLINKS variables which in some cases would produce symlinks
>> within to libexec/, e.g. "git-add" symlinked to "git" which would be
>> copy of the "git" found in bin/, now "git-add" in libexec/ is always
>> going to be symlinked to the "git" found in the bin/ directory.
>
> It is important to leave the default at hard-linking the binaries,
> because on Windows symbolic links are second class citizens (they
> require special privileges and there is a distinction between link
> targets being files or directories). Hard links work well.

Yeah makes sense. I just want to add this as an option, and think if
it's proven to be un-buggy we could probably turn it on by default on
the *nix's if people prefer that, but yeah, we'll definitely need the
uname detection.

>>
>> This option is being added because:
>>
>>   1) I think it makes what we're doing a lot more obvious. E.g. I'd
>>      never noticed that the libexec binaries were really just hardlinks
>>      since e.g. ls(1) won't show that in any obvious way. You need to
>>      start stat(1)-ing things and look at the inodes to see what's
>>      going on.
>>
>>   2) Some tools have very crappy support for hardlinks, e.g. the Git
>>      shipped with GitLab is much bigger than it should be because
>>      they're using a chef module that doesn't know about hardlinks, see
>>      https://github.com/chef/omnibus/issues/827
>>
>>      I've also ran into other related issues that I think are explained
>
> s/ran/run/
>
>>      by this, e.g. compiling git with debugging and rpm refusing to
>>      install a ~200MB git package with 2GB left on the FS, I think that
>>      was because it doesn't consider hardlinks, just the sum of the
>>      byte size of everything in the package.
>>
>> As for the implementation, the "../../bin" noted above will vary given
>> some given some values of "../.." and "bin" depending on the depth of
>
> s/given some//
>
>> the gitexecdir relative to the destdir, and the "bindir" target,
>> e.g. setting "bindir=/tmp/git/binaries gitexecdir=foo/bar/baz" will do
>> the right thing and produce this result:
>>
>>      $ file /tmp/git/foo/bar/baz/git-add
>>      /tmp/git/foo/bar/baz/git-add: symbolic link to ../../../binaries/git
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>   Makefile | 46 +++++++++++++++++++++++++++++++---------------
>>   1 file changed, 31 insertions(+), 15 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index ee0b6c8940..ac7616422d 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -329,6 +329,13 @@ all::
>>   # when hardlinking a file to another name and unlinking the original file right
>>   # away (some NTFS drivers seem to zero the contents in that scenario).
>>   #
>> +# Define INSTALL_SYMLINKS if you prefer to have everything that can be
>> +# symlinked between bin/ and libexec/ to use relative symlinks between
>> +# the two. This option overrides NO_CROSS_DIRECTORY_HARDLINKS and
>
> s/ between the two//

Thanks. Will fix the above in a subsequent submission.

>> +# NO_INSTALL_HARDLINKS which will also use symlinking by indirection
>> +# within the same directory in some cases, INSTALL_SYMLINKS will
>> +# always symlink to the final target directly.
>
> "the final target"? Do you mean "the git executable installed in
> $bindir" or something like this?

I'm not explaining this well, but what I mean is that right now if you
supply NO_INSTALL_HARDLINKS you end up with this:

    bin/git
    libexec/git
    libexec/git-add -> git

I.e. we make two copies of the "git" binary, and then just symlink
within the libexec dir, whereas with this change:

    bin/git
    libexec/git -> ../bin/git
    libexec/git-add -> ../bin/git

I.e. we'll only install one "git" and never copy it, and to the extent
that we need symlinking we're always going to symlink directly to the
binary, i.e. not:

    bin/git
    libexec/git -> ../bin/git
    libexec/git-add -> git

Even though that would also work, I just don't think it makes sense.

>> +#
>>   # Define NO_CROSS_DIRECTORY_HARDLINKS if you plan to distribute the installed
>>   # programs as a tar, where bin/ and libexec/ might be on different file systems.
>>   #
>> @@ -2594,35 +2601,44 @@ endif
>>     	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
>>   	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
>> +	destdir_from_execdir_SQ=$$(echo '$(gitexecdir_relative_SQ)' | sed -e 's|[^/][^/]*|..|g') && \
>>   	{ test "$$bindir/" = "$$execdir/" || \
>>   	  for p in git$X $(filter $(install_bindir_programs),$(ALL_PROGRAMS)); do \
>>   		$(RM) "$$execdir/$$p" && \
>> -		test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
>> -		ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
>> -		cp "$$bindir/$$p" "$$execdir/$$p" || exit; \
>> +		test -n "$(INSTALL_SYMLINKS)" && \
>> +		ln -s "$$destdir_from_execdir_SQ/$(bindir_relative_SQ)/$$p" "$$execdir/$$p" || \
>> +		{ test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
>> +		  ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
>> +		  cp "$$bindir/$$p" "$$execdir/$$p" || exit; } \
>
> I think that it is unnecessary to place the later options in {}
> brackets because && and || have equal precedence in shell
> scripts. That is:
>
> 	want symlinks? &&
> 	make symlinks ||
> 	want hard links? &&
> 	make hard links ||
> 	make copies ||
> 	exit
>
> Of course, it means that when symlinking fails, it falls back to hard
> links (if permitted) or copies, whichever works. But that also happens
> with your version.
>
> (Ditto in the rest of the hunk, which I don't repeat here.)

Yes. This is shitty, I'll change it. I'm going to inject a patch series
earlier in this series so we'll do:

 	want symlinks? &&
 	make symlinks ||
 	want hard links? &&
 	make hard links ||
 	want copy fallback? &&
 	make copies ||
 	exit

And then turn on the copy fallback by default. Right now we'll silently
hide errors during "make install", which isn't nice. I'll leave the
fallback on by default (for now), but I'd like to declare that I want to
install symlinks, and if that fails I should get an error, not a silent
fallback to copy.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-13 12:36       ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
  2018-03-13 18:36         ` Junio C Hamano
@ 2018-03-14 10:18         ` Ævar Arnfjörð Bjarmason
  2018-03-14 16:07           ` Junio C Hamano
  1 sibling, 1 reply; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-14 10:18 UTC (permalink / raw)
  To: Daniel Jacques; +Cc: Johannes Schindelin, git, Junio C Hamano


On Tue, Mar 13 2018, Ævar Arnfjörð Bjarmason jotted:

> On Thu, Mar 08 2018, Daniel Jacques jotted:
>
>>> It would be great to have this rebooted now that my perl cleanup efforts
>>> have un-blocked this. Will be happy to help review & test the next
>>> iteration.
>>
>> Yes, I was just thinking the same thing. I wanted to make sure the Perl
>> changes had landed, and I'm pleased to see that they have. I should have
>> time in the next few days to rebase and put up a new version of the patch
>> series. I'll keep you in the loop, and thanks for pinging!
>
> Related to this, I came across this bug report
> https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is
> wondering why we're installing N copies of the git binary, presumably
> they're building with NO_INSTALL_HARDLINKS.
>
> Just doing this:
>
>     diff --git a/Makefile b/Makefile
>     index de4b8f0c02..2222319a4f 100644
>     --- a/Makefile
>     +++ b/Makefile
>     @@ -2596,7 +2596,7 @@ endif
>               for p in git$X $(filter $(install_bindir_programs),$(ALL_PROGRAMS)); do \
>                     $(RM) "$$execdir/$$p" && \
>                     test -z "$(NO_INSTALL_HARDLINKS)$(NO_CROSS_DIRECTORY_HARDLINKS)" && \
>     -               ln "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
>     +               ln -s "$$bindir/$$p" "$$execdir/$$p" 2>/dev/null || \
>                     cp "$$bindir/$$p" "$$execdir/$$p" || exit; \
>               done; \
>             } && \
>
> Seems to work for me, although obviously this would need to be optional,
> and it'll get in the way of Daniel's patch since it use the absolute
> path.
>
> But is there any reason anyone can think of for why we shouldn't be
> figuring out the relative path and symlinking the two?

Also, as another follow-up question. we have stuff like "git-add" in the
libexec/ directory, but when you run "git add" the bin/git binary just
handles that internally, it's not dispatching to libexec/git-add.

Is the only reason we're still installing these binaries like git-add in
libexec for compatibility with some old installation where that was
added to the $PATH, shouldn't we (and I can write this patch) also have
a toggle for "I want the modern install method" which would not install
any of these binaries like git-add at all?

Then the libexec/ dir would only contain things that we really do need
the bin/git to dispatch to, like git-svn, git-bisect etc.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-14 10:18         ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
@ 2018-03-14 16:07           ` Junio C Hamano
  2018-03-15 17:16             ` Johannes Schindelin
  0 siblings, 1 reply; 28+ messages in thread
From: Junio C Hamano @ 2018-03-14 16:07 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Daniel Jacques, Johannes Schindelin, git

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Is the only reason we're still installing these binaries like git-add in
> libexec for compatibility with some old installation where that was
> added to the $PATH, shouldn't we (and I can write this patch) also have
> a toggle for "I want the modern install method" which would not install
> any of these binaries like git-add at all?
>
> Then the libexec/ dir would only contain things that we really do need
> the bin/git to dispatch to, like git-svn, git-bisect etc.

Removing them by default was proposed and failed; see this thread
for example:

  https://public-inbox.org/git/7vr68b8q9p.fsf@gitster.siamese.dyndns.org/#t

If a packager ships Git without these copies in libexec, that is not
the Git that promised users that prepending the $(git --exec-path)
aka GIT_EXEC_PATH to your $PATH is a valid way to preserve their
older script.

I do not think anybody actually minds to have an option to omit them
as long as the users understand the consequence (i.e. old promises
broken) and know they are not affected (i.e. they do not have
scripts that rely on the old promise).

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-14 10:14               ` Ævar Arnfjörð Bjarmason
@ 2018-03-14 17:21                 ` Linus Torvalds
  2018-03-15 17:05                   ` Johannes Schindelin
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Torvalds @ 2018-03-14 17:21 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Johannes Sixt, Git Mailing List, Junio C Hamano, Daniel Jacques,
	Johannes Schindelin, Steffen Prohaska, John Keeping, Stan Hu,
	Richard Clamp

On Wed, Mar 14, 2018 at 3:14 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Wed, Mar 14 2018, Johannes Sixt jotted:
>>
>> It is important to leave the default at hard-linking the binaries,
>> because on Windows symbolic links are second class citizens (they
>> require special privileges and there is a distinction between link
>> targets being files or directories). Hard links work well.
>
> Yeah makes sense. I just want to add this as an option, and think if
> it's proven to be un-buggy we could probably turn it on by default on
> the *nix's if people prefer that, but yeah, we'll definitely need the
> uname detection.

I definitely would prefer to make symlinks the default on unix.

It's what we used to do (long long ago), and as you pointed out, it's
a lot clearer what's going on too when you don't have to look at inode
numbers and link counts.

Forcing hardlinking everywhere by default just because Windows
filesystems suck donkey ass through a straw is not the right thing
either.

                Linus

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-14  7:20             ` Johannes Sixt
  2018-03-14 10:14               ` Ævar Arnfjörð Bjarmason
@ 2018-03-15 17:03               ` Johannes Schindelin
  1 sibling, 0 replies; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-15 17:03 UTC (permalink / raw)
  To: Johannes Sixt
  Cc: Ævar Arnfjörð Bjarmason, git, Junio C Hamano,
	Daniel Jacques, Steffen Prohaska, John Keeping, Stan Hu,
	Richard Clamp

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

Hi,

On Wed, 14 Mar 2018, Johannes Sixt wrote:

> Am 13.03.2018 um 21:39 schrieb Ævar Arnfjörð Bjarmason:
> > Add a INSTALL_SYMLINKS option which if enabled, changes the default
> > hardlink installation method to one where the relevant binaries in
> > libexec/git-core are symlinked back to ../../bin, instead of being
> > hardlinked.
> > 
> > This new option also overrides the behavior of the existing
> > NO_*_HARDLINKS variables which in some cases would produce symlinks
> > within to libexec/, e.g. "git-add" symlinked to "git" which would be
> > copy of the "git" found in bin/, now "git-add" in libexec/ is always
> > going to be symlinked to the "git" found in the bin/ directory.
> 
> It is important to leave the default at hard-linking the binaries, because on
> Windows symbolic links are second class citizens (they require special
> privileges and there is a distinction between link targets being files or
> directories). Hard links work well.

To clarify: symbolic links do not exist in Windows Vista and earlier.
(There exists a concept called Junction points, but it has subtly
different semantics than symbolic links, different enough that we cannot
emulate symbolic links via Junctions).

Windows 7 and later do have symbolic links, but they require elevated
privileges to be created, as Hannes pointed out.

Since Windows 10 version 1703 (Creators Update), enabling Developer Mode
will disable this restriction and allow creating symlinks without UAC
elevation. See
https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ for
details.

In Git for Windows, I originally missed the memo and forgot to add support
for the special flag, but since Git for Windows v2.13.1, users can create
symbolic links without administrators' privileges on Windows 10 (Creators
Update or later) in Developer Mode.

Of course, we still support Windows all the way back to Vista, so the
default is still: no symbolic links.

Thanks for your attention,
Dscho

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-14 17:21                 ` Linus Torvalds
@ 2018-03-15 17:05                   ` Johannes Schindelin
  2018-03-15 17:42                     ` Linus Torvalds
  0 siblings, 1 reply; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-15 17:05 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ævar Arnfjörð Bjarmason, Johannes Sixt,
	Git Mailing List, Junio C Hamano, Daniel Jacques,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp

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

Hi Linus,

On Wed, 14 Mar 2018, Linus Torvalds wrote:

> On Wed, Mar 14, 2018 at 3:14 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> > On Wed, Mar 14 2018, Johannes Sixt jotted:
> >>
> >> It is important to leave the default at hard-linking the binaries,
> >> because on Windows symbolic links are second class citizens (they
> >> require special privileges and there is a distinction between link
> >> targets being files or directories). Hard links work well.
> >
> > Yeah makes sense. I just want to add this as an option, and think if
> > it's proven to be un-buggy we could probably turn it on by default on
> > the *nix's if people prefer that, but yeah, we'll definitely need the
> > uname detection.
> 
> I definitely would prefer to make symlinks the default on unix.
> 
> It's what we used to do (long long ago), and as you pointed out, it's
> a lot clearer what's going on too when you don't have to look at inode
> numbers and link counts.
> 
> Forcing hardlinking everywhere by default just because Windows
> filesystems suck donkey ass through a straw is not the right thing
> either.

The most sensible thing, of course, would be to *not* link the builtins at
all. I mean, we deprecated the dashed form (which was a design mistake,
whether you admit it or not) a long time ago.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-14 16:07           ` Junio C Hamano
@ 2018-03-15 17:16             ` Johannes Schindelin
  2018-03-16 17:29               ` Duy Nguyen
  0 siblings, 1 reply; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-15 17:16 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Ævar Arnfjörð Bjarmason, Daniel Jacques, git

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

Hi Junio,

On Wed, 14 Mar 2018, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > Is the only reason we're still installing these binaries like git-add in
> > libexec for compatibility with some old installation where that was
> > added to the $PATH, shouldn't we (and I can write this patch) also have
> > a toggle for "I want the modern install method" which would not install
> > any of these binaries like git-add at all?
> >
> > Then the libexec/ dir would only contain things that we really do need
> > the bin/git to dispatch to, like git-svn, git-bisect etc.
> 
> Removing them by default was proposed and failed; see this thread
> for example:
> 
>   https://public-inbox.org/git/7vr68b8q9p.fsf@gitster.siamese.dyndns.org/#t

Let's add a very, very important piece of information that was missing:
this thread is from late August 2008. We had deprecated the dashed form
"only for a couple of months" by then (we removed the dashed form from the
completions end of April 2008 in 799596a5d06 (completion: remove use of
dashed git commands, 2008-04-20) for example).

> If a packager ships Git without these copies in libexec, that is not
> the Git that promised users that prepending the $(git --exec-path)
> aka GIT_EXEC_PATH to your $PATH is a valid way to preserve their
> older script.
> 
> I do not think anybody actually minds to have an option to omit them
> as long as the users understand the consequence (i.e. old promises
> broken) and know they are not affected (i.e. they do not have
> scripts that rely on the old promise).

I am glad that you changed your stance from "without dashed builtins, your
Git is broken" to this much more tenable position to state that it may
break super-old promises whose use we discouraged already a full decade
ago.

To add some interesting information to this: in MinGit (the light-weight
"Git for applications" we bundle to avoid adding a hefty 230MB to any
application that wants to bundle Git for Windows), we simply ignored that
old promise. We do support hooks written as Unix shell scripts in MinGit,
and we have not had a single report since offering MinGit with v2.9.2 on
July 16th, 2016, that it broke anybody's scripts, so it seems that users
are more sensible than our promises ;-)

Not requiring Git to install any type of link makes it even possible to
bundle it as .zip file (which, let's face it, is the de facto standard for
cross-platform archiving).

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-15 17:05                   ` Johannes Schindelin
@ 2018-03-15 17:42                     ` Linus Torvalds
  2018-03-16 11:48                       ` Johannes Schindelin
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Torvalds @ 2018-03-15 17:42 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Ævar Arnfjörð Bjarmason, Johannes Sixt,
	Git Mailing List, Junio C Hamano, Daniel Jacques,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp

On Thu, Mar 15, 2018 at 10:05 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> The most sensible thing, of course, would be to *not* link the builtins at
> all. I mean, we deprecated the dashed form (which was a design mistake,
> whether you admit it or not) a long time ago.

That's probably not a bad idea for the builtin commands. At least as an option.

We do end up still using the dashed form for certain things, but they
are already special-cased (ie things like "git-receive-pack" and
"git-shell" that very much get executed directly, and for fundamental
reasons).

As to it being a design mistake? No, not really. It made a lot of
sense at the time. The fact is, the problem is Windows, not git. I
know you have your hangups, but that's your problem.

               Linus

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-15 17:42                     ` Linus Torvalds
@ 2018-03-16 11:48                       ` Johannes Schindelin
  2018-03-16 12:43                         ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-16 11:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ævar Arnfjörð Bjarmason, Johannes Sixt,
	Git Mailing List, Junio C Hamano, Daniel Jacques,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp

Hi Linus.

On Thu, 15 Mar 2018, Linus Torvalds wrote:

> We do end up still using the dashed form for certain things, but they
> are already special-cased (ie things like "git-receive-pack" and
> "git-shell" that very much get executed directly, and for fundamental
> reasons).

Please do elaborate.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-16 11:48                       ` Johannes Schindelin
@ 2018-03-16 12:43                         ` Ævar Arnfjörð Bjarmason
  2018-03-19 11:34                           ` Johannes Schindelin
  0 siblings, 1 reply; 28+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-03-16 12:43 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Linus Torvalds, Johannes Sixt, Git Mailing List, Junio C Hamano,
	Daniel Jacques, Steffen Prohaska, John Keeping, Stan Hu,
	Richard Clamp


On Fri, Mar 16 2018, Johannes Schindelin jotted:

> Hi Linus.
>
> On Thu, 15 Mar 2018, Linus Torvalds wrote:
>
>> We do end up still using the dashed form for certain things, but they
>> are already special-cased (ie things like "git-receive-pack" and
>> "git-shell" that very much get executed directly, and for fundamental
>> reasons).
>
> Please do elaborate.

If you were to set set "/bin/git shell" in /etc/password it would not do
the right thing as far as I know. Is that a shell name with a space in
it, or the "shell" argument to /bin/git?

There's also the fully dashed forms of stuff like git-receive-pack is
part of the over-ssh convention, i.e.:

    ssh <host> git-upload-pack ...

That being said I think Linus is conflating two things here. If we still
had just the dashed forms on *nix we'd still have the issue of what it
does to shell completion, which is one thing that got brought up in the
discussion to create the "git" wrapper at the time. There were also
other reasons IIRC.

That's an entirely separate discussion from how we go about either hard-
or symlinking some stuff git is using, whether or not that's ever
directly exposed to the user.

Having said that I have a WIP re-roll which where I'm aiming to:

 * Add a NO_INSTALL_CP_FALLBACK flag, so we won't implicitly fall back
   to cp silently (unless told so)

 * Remove the 2>/dev/null we're doing on everything. That pre-dates the
   NO_*_*HARDLINKS flags and we shouldn't be doing that anymore.

 * Add an option where we optionally won't install the majority of these
   dashed forms, regardless of whether we choose hardlinks or
   symlinks. We'll still need some linking as some dashed forms we can't
   remove, as noted above.

I didn't expect Junio to merge this down to `next` so fast, so I'll wait
until INSTALL_SYMLINKS lands. As far as I know the code as-is in next
isn't buggy, I'd just like to improve it a bit more, so I'll need to
rebase what I have on top of that (which is fine).

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-15 17:16             ` Johannes Schindelin
@ 2018-03-16 17:29               ` Duy Nguyen
  2018-03-30  8:59                 ` Johannes Schindelin
  0 siblings, 1 reply; 28+ messages in thread
From: Duy Nguyen @ 2018-03-16 17:29 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason,
	Daniel Jacques, Git Mailing List

On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> To add some interesting information to this: in MinGit (the light-weight
> "Git for applications" we bundle to avoid adding a hefty 230MB to any
> application that wants to bundle Git for Windows), we simply ignored that
> old promise. We do support hooks written as Unix shell scripts in MinGit,
> and we have not had a single report since offering MinGit with v2.9.2 on
> July 16th, 2016, that it broke anybody's scripts, so it seems that users
> are more sensible than our promises ;-)

That's very good to hear. Perhaps we could slowly move away from
symlinking (or even hard linking) these builtin commands (with a
couple exception like receive-pack and stuff) ? We don't have to do it
right now but we can start announcing that we will drop it in maybe 2
or 3 releases. We do provide a new make target to recreate these links
so that packagers can make a "compat" package that contains just these
links if they want to. But by default a git package will have no
links.
-- 
Duy

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-16 12:43                         ` Ævar Arnfjörð Bjarmason
@ 2018-03-19 11:34                           ` Johannes Schindelin
  2018-03-19 21:21                             ` Linus Torvalds
  0 siblings, 1 reply; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-19 11:34 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Linus Torvalds, Johannes Sixt, Git Mailing List, Junio C Hamano,
	Daniel Jacques, Steffen Prohaska, John Keeping, Stan Hu,
	Richard Clamp

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

Hi Ævar,

On Fri, 16 Mar 2018, Ævar Arnfjörð Bjarmason wrote:

> 
> On Fri, Mar 16 2018, Johannes Schindelin jotted:
> 
> > On Thu, 15 Mar 2018, Linus Torvalds wrote:
> >
> >> We do end up still using the dashed form for certain things, but they
> >> are already special-cased (ie things like "git-receive-pack" and
> >> "git-shell" that very much get executed directly, and for fundamental
> >> reasons).
> >
> > Please do elaborate.
> 
> If you were to set set "/bin/git shell" in /etc/password it would not do
> the right thing as far as I know. Is that a shell name with a space in
> it, or the "shell" argument to /bin/git?

True. And `git-shell` is not a builtin, so it does not even matter with
regards to this discussion.

> There's also the fully dashed forms of stuff like git-receive-pack is
> part of the over-ssh convention, i.e.:
> 
>     ssh <host> git-upload-pack ...

Even if upload-pack is not a builtin (and thus still has to be its own
executable), receive-pack *is*, so this does affect our current
discussion.

This is a real problem. And it is our own darned fault because we let an
implementation detail bleed into a protocol. We could have designed that a
lot better.

Of course we should fix this, though. There is literally no good reason
that I can think of why we should not change this to `ssh <host> git
upload-pack ...` (of course with an insanely long deprecation period).

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git
  2018-03-19 11:34                           ` Johannes Schindelin
@ 2018-03-19 21:21                             ` Linus Torvalds
  0 siblings, 0 replies; 28+ messages in thread
From: Linus Torvalds @ 2018-03-19 21:21 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Ævar Arnfjörð Bjarmason, Johannes Sixt,
	Git Mailing List, Junio C Hamano, Daniel Jacques,
	Steffen Prohaska, John Keeping, Stan Hu, Richard Clamp

On Mon, Mar 19, 2018, 04:34 Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> This is a real problem.

No it isn't.

We already handle those special cases specially, and install them in
the bin directory (as opposed to libexec). And it all works fine.

Look into the bin directory some day. You'll find things like

  git-cvsserver
  gitk
  git-receive-pack
  git-shell
  git-upload-archive
  git-upload-pack

there, and the fact that a couple of them happen to be built-ins is an
IMPLEMENTATION DETAIL, not a "Oh we should have used just 'git' for
them".

The design of having separate programs is the *good* conceptual
design. And we damn well should keep it for these things that are used
for special purposes.

The fact that two of them have become built-ins as part of the git
binary is incidental. It shouldn't be visible in the names, because it
really is just an internal implementation thing, not anything
fundamental.

> And it is our own darned fault because we let an
> implementation detail bleed into a protocol. We could have designed that a
> lot better.

And by "we" you clearly mean "not you", and by "we could have designed
that a lot better" you must mean "and it was very well designed by
competent people who didn't use bad operating systems".

> Of course we should fix this, though. There is literally no good reason

Go away.

We shouldn't fix it, it's all fine as-is, and there were tons of
f*cking good reasons for why git did what it did. The main one being
"it's a collection of scripts", which was what git _was_, for
chrissake. And using spaces and running some idiotic and
hard-to-verify script de-multiplexer is the WRONG THING for things
like "git-shell" and "git-receive-pack" and friends.

Right now you can actually verify exactly what "git-shell" does. Or
you could replace - or remove - it entirely if you don't like it. And
never have to worry about running "git" with some "shell" subcommand.

And you know that it's not an alias, for example.  Because "git-xyz"
simply does not look up aliases.

So really. Go away, Johannes. Your concerns are complete and utter BS.

The real problem is that Windows is badly designed, but since it's
easy to work around (by using hard-linking on Windows), nobody sane
cares.

The solution is simple, and was already suggested: use symlinks (like
we used to!) on non-windows systems. End of story.

And for the libexec thing, we might want to deprecate those names, if
somebody wants to, but it's not like it actually hurts, and it gives
backwards compatibility.

Btw, real Windows people know all about backwards compatibility. Ask
around competent people inside MS whether it's an important thing.

So stop this idiotic "bad design" crap. Somebody working on Windows
simply can't afford your attitude.

Somebody who didn't design it in the first place can't afford your attitude.

                         Linus

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: Why don't we symlink libexec/git-core/* to bin/git?
  2018-03-16 17:29               ` Duy Nguyen
@ 2018-03-30  8:59                 ` Johannes Schindelin
  0 siblings, 0 replies; 28+ messages in thread
From: Johannes Schindelin @ 2018-03-30  8:59 UTC (permalink / raw)
  To: Duy Nguyen
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason,
	Daniel Jacques, Git Mailing List

Hi Duy,

On Fri, 16 Mar 2018, Duy Nguyen wrote:

> On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > To add some interesting information to this: in MinGit (the
> > light-weight "Git for applications" we bundle to avoid adding a hefty
> > 230MB to any application that wants to bundle Git for Windows), we
> > simply ignored that old promise. We do support hooks written as Unix
> > shell scripts in MinGit, and we have not had a single report since
> > offering MinGit with v2.9.2 on July 16th, 2016, that it broke
> > anybody's scripts, so it seems that users are more sensible than our
> > promises ;-)
> 
> That's very good to hear. Perhaps we could slowly move away from
> symlinking (or even hard linking) these builtin commands (with a
> couple exception like receive-pack and stuff) ?

I would hope so. As I said before: the fact that Git started out with
everything as dashed subcommands is an implementation detail that
unfortunately leaked into many parts of Git's UI. We can fix this.

> We don't have to do it right now but we can start announcing that we
> will drop it in maybe 2 or 3 releases. We do provide a new make target
> to recreate these links so that packagers can make a "compat" package
> that contains just these links if they want to. But by default a git
> package will have no links.

I think that makes a *ton* of sense. Let's get to work after v2.17.0?
(Same for your excellent work on t/helper/test-tool)

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, back to index

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-06 23:34 What's cooking in git.git (Mar 2018, #02; Tue, 6) Junio C Hamano
2018-03-07 12:34 ` Johannes Schindelin
2018-03-08  9:22   ` Ævar Arnfjörð Bjarmason
2018-03-08 13:12     ` Daniel Jacques
2018-03-13 12:36       ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
2018-03-13 18:36         ` Junio C Hamano
2018-03-13 19:32           ` Randall S. Becker
2018-03-13 20:39           ` [PATCH 0/3] Makefile: add a INSTALL_SYMLINKS option Ævar Arnfjörð Bjarmason
2018-03-13 20:39           ` [PATCH 1/3] Makefile: fix broken bindir_relative variable Ævar Arnfjörð Bjarmason
2018-03-13 20:39           ` [PATCH 2/3] Makefile: add a gitexecdir_relative variable Ævar Arnfjörð Bjarmason
2018-03-13 20:39           ` [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git Ævar Arnfjörð Bjarmason
2018-03-14  7:20             ` Johannes Sixt
2018-03-14 10:14               ` Ævar Arnfjörð Bjarmason
2018-03-14 17:21                 ` Linus Torvalds
2018-03-15 17:05                   ` Johannes Schindelin
2018-03-15 17:42                     ` Linus Torvalds
2018-03-16 11:48                       ` Johannes Schindelin
2018-03-16 12:43                         ` Ævar Arnfjörð Bjarmason
2018-03-19 11:34                           ` Johannes Schindelin
2018-03-19 21:21                             ` Linus Torvalds
2018-03-15 17:03               ` Johannes Schindelin
2018-03-14 10:18         ` Why don't we symlink libexec/git-core/* to bin/git? Ævar Arnfjörð Bjarmason
2018-03-14 16:07           ` Junio C Hamano
2018-03-15 17:16             ` Johannes Schindelin
2018-03-16 17:29               ` Duy Nguyen
2018-03-30  8:59                 ` Johannes Schindelin
2018-03-09  6:15 ` What's cooking in git.git (Mar 2018, #02; Tue, 6) Martin Ågren
2018-03-09  9:54   ` Duy Nguyen
2018-03-09 17:19   ` Junio C Hamano

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox