ingydotnet / git-subrepo

MIT License
3.25k stars 269 forks source link

'git-subrepo' DEB packaging #471

Open spog opened 4 years ago

spog commented 4 years ago

Hi,

I made a sample project for packaging your great git-subrepo extension into a DEB package. The packaging project itself (https://github.com/spog/git-subrepo-debian.git) uses a subrepo to import required version of 'git-subrepo' code. There is also an Ubintu-bionic 'git-subrepo' packaga already available on my PPA: https://launchpad.net/~spog/+archive/ubuntu/ppa

I hope there is some interest about packaged 'git-subrepo'?

regards, Samo

p.s. I would suggest, that you mention somewhere in docs, that specifying a branch on the 'subrepo' command line may also be a tag name or a commit checksum. It is not clear, since i ran into a tutorial (https://sudonull.com/post/8961-Git-subrepo) explicitly stating: ...the user cannot connect a subproject referring to his fixed tag or a specific revision,... or maybe i got it all wrong

admorgan commented 4 years ago

I think it is awesome that you packaged it for Debian.

As for using an explicit rev/tag for the branch does work. It prevents the pull feature from working, but I use that feature extensively for some of my use cases. I agree this should be added as an advanced "feature" in the documentation.

spog commented 4 years ago

Thanks for the quick reply. There is a glitch in DEB auto-completion support, since (ubutu-18.04 / git-2.17 - my installation) does not provide dynamic completion scripts loading from the git completion script itself. The next git-2.18 however does. Currently i need to source the DEB installed '/usr/share/bash-completion/completions/git-subrepo' via .bashrc or to fix git's '/usr/share/bash-completion/completions/git'. I'd like to hear, if there were some other issues too.

perlpunk commented 4 years ago

Good idea! I'm working on getting this into openSUSE too https://build.opensuse.org/package/show/home:tinita:branches:devel:tools:scm/git-subrepo

admorgan commented 4 years ago

Just a heads up, but 2.17 is the oldest version of git that is supported. I don't even have a CI system to test it against any longer. I am really excited about all the packaging.

spog commented 4 years ago

Thanks for more info. I am currently preparing packages for all live Ubuntu distros from 16.04 up to 20.04. and then think about Debian itself. Does it make sense to make package for Xenial (16.04 with git-2.7.4) - already done - as you mentioned 2.17?

perlpunk commented 4 years ago

2.17 is the oldest version of git that is supported

Did you mean 2.7?

admorgan commented 4 years ago

@perlpunk I did mean 2.7. Also when I looked at your oipenSUSE patch you have modifications to edit the shebangs. I am curios why this is necessary. I am running openSUSE and it works fine with #!/usr/bin/env bash

perlpunk commented 4 years ago

@admorgan We are modifying the shebang of all scripts to use the actual program instead of env. It would of course work with env. But using env in distribution packages can have drawbacks. So for example git-subrepo is installed for the corresponding bash version that was installed when building the package. If a user is using a different version of bash in their path, then it could possibly break. In this case that's unlikely, but that's the reason why such packages don't use env.

admorgan commented 4 years ago

Interesting, since that is one of the reasons to use it, especially on OSX using homebrew to get a modern bash shell.

perlpunk commented 4 years ago

True, there are such use cases. But if you are using homebrew on a system to install a newer bash, you can also install the git-subrepo package with homebrew. Packages installed via the system's package manager should be reliable and work with the bash version they were tested and built with.

perlpunk commented 4 years ago

Hm, I'm having a problem with the zsh completion on openSUSE.

git subrepo <TAB>
GIT_SUBREPO_ROOT is null; has `/path/to/git-subrepo/.rc` been sourced?

I wonder if that is still necessary: https://github.com/ingydotnet/git-subrepo/blob/master/share/zsh-completion/_git-subrepo#L6-L9

I added zsh completion, but cannot remember why this was necessary ;-)

perlpunk commented 4 years ago

What I also noticed: make test doesn't work when run from a directory without git, e.g. from a tarball. Is this necessary? It would be cool if we could run the tests when building the rpm (or deb) package.

admorgan commented 4 years ago

True, there are such use cases. But if you are using homebrew on a system to install a newer bash, you can also install the git-subrepo package with homebrew. Packages installed via the system's package manager should be reliable and work with the bash version they were tested and built with.

Unfortunately homebrew's install of bash doesn't remove the system installed version, it just adds a second version that runs on top of it. So your bash shell actually runs a newer bash on top of an older bash.

admorgan commented 4 years ago

@perlpunk In my opinion not being able to run tests in a non-git directory is a bug. Lets move that into another issue so it can get monitors/updated.

perlpunk commented 4 years ago

@spog you say you are having problems with completion. For me, completion works only partially, both with bash and zsh. Not working: git subr<TAB> Working: git subrepo <TAB> Even if I explicitly do: /usr/share/bash-completion/completions/git-subrepo

I have git 2.26.2 on that machine. Do you have similar problems?

spog commented 4 years ago

@perlpunk interesting, i see the same behaviour of bash completion in "eoan" (git version 2.20.1) and "focal" (git version 2.25.1) ubuntu versions, however there is exactly oposite behaviour in "bionic" (git version 2.17.1).

perlpunk commented 4 years ago

git-subrepo has been accepted for openSUSE:Factory, which means that it will be in Tumbleweed soon, and in the next openSUSE Leap. https://build.opensuse.org/package/show/openSUSE:Factory/git-subrepo

spog commented 4 years ago

@perlpunk good job.

i did some digging regarding git bash_completion support and it turns out, that generation of a list of all git commands changed. As i see it, it is currently only possible to to change the list by setting environment variable GIT_TESTING_PORCELAIN_COMMAND_LIST. Unfortunately the name suggests 'testing purposes', but this seems to be the only alternative available in /usr/share/bash-completion/completions/git. Any other suggestion?

I am currently playing with adding something like this:

cat /etc/profile.d/git-subrepo.sh 
if [ -n "${GIT_TESTING_PORCELAIN_COMMAND_LIST}" ]; then
    export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(echo $GIT_TESTING_PORCELAIN_COMMAND_LIST | sed 's% subrepo%%g') subrepo"
else
    export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=list-mainporcelain,others,nohelpers,alias,list-complete,config) subrepo"
fi
perlpunk commented 4 years ago

@spog what I'm wondering about is, git <TAB> works here if I use it from the git repo. Maybe one difference is, that git-subrepo is an executable command in $PATH when using .rc. When it is installed, then it's just a non-executable file in /usr/lib/git.

spog commented 4 years ago

@perlpunk tried with a symlink and with a copy in /usr/bin/, but it does not do the trick.

perlpunk commented 4 years ago

hm, right. Also I was wrong, the file is indeed executable, and it did not help to add /usr/lib/git to $PATH for bash. Your script works for me with bash.

For zsh OTOH, it just works if I add /usr/lib/git to $PATH. I guess the zsh git completion does things differently...

:)