Re: Why don't we symlink libexec/git-core/* to bin/git?

[Johannes Schindelin]

Hi Duy,

On Fri, 16 Mar 2018, Duy Nguyen wrote:

> On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin
>  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

Re: Why don't we symlink libexec/git-core/* to bin/git?

[Duy Nguyen]

On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin
 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

Re: Why don't we symlink libexec/git-core/* to bin/git?

[Johannes Schindelin]

Hi Junio,

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

> Ævar Arnfjörð Bjarmason  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@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

Re: Why don't we symlink libexec/git-core/* to bin/git?

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  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@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).

Re: Why don't we symlink libexec/git-core/* to bin/git?

[Ævar Arnfjörð Bjarmason]

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..319a4f 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.

RE: Why don't we symlink libexec/git-core/* to bin/git?

[Randall S. Becker]

On March 13, 2018 2:37 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason  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 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Re: Why don't we symlink libexec/git-core/* to bin/git?

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  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.