Why:
val git = Git
.cloneRepository()
.setURI(s"https://github.com/whatever/whatever.git")
.call()
println(git.getRepository.getConfig.getBoolean("core", "fileMode", true))
// Prints false
Whereas if I read the documentation:
https://git-scm.com/docs/git-config#git-config-corefileMode
The default is true (when core.filemode is not specified in the config file).
So why JGit decide for me to override core.filemode?
Cheers
JGit sets the filemode differently on windows and unix-like operating systems. Since windows does not have an executable bit the default is false here.
Alright, I opened an issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=519887
And provided a fix:
https://git.eclipse.org/r/101582
Related
i would like cloud-init to not use 50-cloud-init.yaml. I have prepared my own file.
Do you know how to do this
You can add
network:
config: disabled
to /etc/cloud/cloud.cfg or a file in /etc/cloud/cloud.cfg.d.
Another option is to add
network-config=disabled
to the kernel command line.
While the network config yaml technically works as userdata, the network configuration will have already been written out before userdata is read.
One other option is to write your netplan configuration into /etc/netplan/99-some-name.yaml. If you have configuration there that overlaps with what is in 50-cloud-init.yaml, your configuration will override what is in the default configuration.
See https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#disabling-network-configuration .
Here's a transcript so far:
$ sbt new lagom/lagom-scala.g8
[info] Loading global plugins from /Users/abrahma/.sbt/1.0/plugins
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
ssh://git#github.com/lagom/lagom-scala.g8.git: Auth fail
I've verified authentication with
GitHub:
$ ssh -T git#github.com
Hi agam! You've successfully authenticated, but GitHub does not provide shell access.
Also verified that I can access the repo in question (i.e. I can do the following, in a separate location):
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
Edit: fwiw I'm able to work around whatever the root cause is here:
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
g8 file:///Users/abrahma/tmp/lagom-scala.g8
I ran into this problem as well, and solved it by removing the following from my ~/.gitconfig:
[url "git#github.com:"]
insteadOf = https://github.com/
Are you using OpenSSH 7.8 or newer, and have you recently created your private key?
If so you might be running into the issue described in “Invalid privatekey” when using JSch aka jsch#129.
The root cause was discovered to be the ssh private key mismatch.
The question has a workaround to convert the key file to an older format if that's the error you're seeing.
You need to add your SSH key to the agent:
ssh-add ~/.ssh/id_rsa
I had a repository named tags, I renamed it to tag.
I then created a new repository named tags (the old name of the first one).
Now when commiting from R Studio both projects try to commit to the same repository (tags).
I initiated my projects with :
shell("git remote add origin https://github.com/moodymudskipper/tag.git", intern = TRUE)
shell("git push -u origin master",intern = TRUE)
and
shell("git remote add origin https://github.com/moodymudskipper/tags.git",intern = TRUE)
shell("git push -u origin master",intern = TRUE)
And after this I only committed through Rstudio's API and usethis functions, I don't know much more than that about git.
Links to the packages :
https://github.com/moodymudskipper/tag
https://github.com/moodymudskipper/tags
How can I sort this out ?
I'm hesitant to throw this out as an answer, but: you can manually edit the ./.git/config file to update the [remote ...] section to change the remote URL. I have done this confidently enough with an empty repo ...
Check for presence of the tag with grep -rli tags.git .git/*; if all you get is .git/config, then you're good to edit and move on. If you find other files, though, I don't know for certain that they will be updated as you continue with your git remote work. In that case, it might be helpful to look at https://help.github.com/en/articles/changing-a-remotes-url in order to formally change the URL.
How can I verify if my code on vim (Unix) has syntax errors?
Is there any command to test the code?
Thank you in advance!
Use a plugin which checks your code.
The one I use, and I'm not alone, is syntactic: https://github.com/vim-syntastic/syntastic
This works for a tons of different languages and even has multiple "lint" engines to choose from for each language. For instance, I use python and can configure syntactic to use one of the following checkers: flake8, pyflakes, pylint and the native python checker. And, yes, it checks vim script as well.
If you can't use any plugins AND only want to debug your vim-scripts, then your best bet is to use vim's own debugger (help debug-scripts). To use this mode:
Start vim in debug mode: vim -D my_broken_script.vim
use :debug to switch into debug mode.
use Ex commands to inspect local variables, echo idx, or global ones: echo g:idx, where idx is the var.
set breakpoints with :breakadd on either functions or files. And delete them with :breakdel
Use profile to investigate performance issues (help :profile): :profile start func and :profile stop
My buildout.cfg for a plone project uses a kgs (known good set):
[buildout]
extends = http://dist.plone.org/release/4.2/versions.cfg
Since it's a network dependency, buildout does not work when being offline.
$ bin/buildout -o
While:
Initializing.
Error: Couldn't download 'http://dist.plone.org/release/4.2/versions.cfg' in offline mode.
What is the best practice to work in offline mode and having kgs references? I assume there is some way to cache external references. Of course I could use a caching proxy locally but there must IMHO be a more lightweight solution.
We always download the KGS URLs to local files and use that as an extends instead:
curl -o plone-versions.cfg http://dist.plone.org/release/4.2.4/versions.cfg
where our versions.cfg reads:
[buildout]
extends =
zopeapp-versions.cfg
ztk-versions.cfg
zope-versions.cfg
plone-versions.cfg
We add a header to the file to name the original source, and comment out the URL extends in the files:
# Sourced from http://dist.plone.org/release/4.2.4/versions.cfg
[buildout]
# extends = http://download.zope.org/zopetoolkit/index/1.0.7/zopeapp-versions.cfg
# http://download.zope.org/Zope2/index/2.13.19/versions.cfg
You can use the extends cache (which can also be shared between different machines such as your development machine and the production machine).
Setup
Add a file at ~/.buildout/default.cfg for enabling the cache for all buildouts on this machine:
[buildout]
extends-cache = /path/to/your/extends/cache
Or you can do the same configuration in a specific buildout.
This will create files with hashed filenames in the directory you configure. Since the name of the file is generated by the URL of the extends, it can easily be copied around. So if you never have an internet connection on the server, you can run the buildout on another server with extends-cache and copy the direct
I just made an odd observation, with could be of interest:
Changing the extends-url from
extends = http://dist.plone.org/release/4.2/versions.cfg
to
extends = http://dist.plone.org/release/4-latest/versions.cfg
will let buildout run without any errors (why?)
Might be a faster solution for your case, but Martijn's answer is of course the way to go for a replicable, controlled development-enviroment.