Re: Why don't we symlink libexec/git-core/* to bin/git?
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?
On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelinwrote: > 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?
Hi Junio, On Wed, 14 Mar 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmasonwrites: > > > 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?
Ævar Arnfjörð Bjarmasonwrites: > 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?
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?
On March 13, 2018 2:37 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmasonwrites: > > > 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?
Ævar Arnfjörð Bjarmasonwrites: > 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.
Why don't we symlink libexec/git-core/* to bin/git?
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?