This is impossible. HTTP protocol is different, because there is a "virtual host" concept and HAProxy can differentiate different hosts using "Host:" header. SSH has nothing like this and so the lxc-host is unable to know the container, you are trying to connect.
But you can use another SSH feature called "SSH gateway". Inside ~/.ssh/authorized_keys there is a command= option. Firts setup key-based ssh from your lxc-host to apple and orange. Then put these lines into lxc's authorized_keys file:
command="ssh -q -t user@apple $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAsomeB3N...== user@client
command="ssh -q -t user@orange $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAanotherB3N...== user@client
Now the lxs host can automatically connect to apple and orange, based on the client key.
See more:
https://serverfault.com/questions/329529/virtual-hosts-for-ssh
http://blog.lick-me.org/2012/06/ssh-gateway-shenanigans/
dans C:\Program Files\Git\cmd> start-ssh-pageant
:ssh-pageant-done
gpgconf --launch gpg-agent
:failure
For some users, it may be desirable to tie OpenSSH in to the PuTTY authentication agent (Pageant) using ssh-pageant. This is a drop-in replacement for ssh-agent, which simply builds a connection between OpenSSH and Pageant for key-based authentication. The tool makes it easy to leverage OpenSSH for remote repository access, which tends to be the most reliable choice within the specific context of Git for Windows (Git), without the need to run multiple agents which don't interoperate.
This functionality became available with the release of Git 2.8.2.
If you always use Git from within Git Bash, then the most straightforward approach is to have it launch ssh-pageant on your behalf. Simply create/edit your _$HOME/.bashprofile (or $HOME/.profile, if you prefer), and add the following.
# ssh-pageant allows use of the PuTTY authentication agent (Pageant)
SSH_PAGEANT="$(command -v ssh-pageant)"
if [ -x "$SSH_PAGEANT" ]; then
eval $("$SSH_PAGEANT" -qra "${SSH_AUTH_SOCK:-${TEMP:-/tmp}/.ssh-pageant-$USERNAME}")
fi
unset SSH_PAGEANT
The -qra "${TEMP:-/tmp}/.ssh-pageant"
construct is equivalent to the -q -r -a filename
options. In this context it means:
By specifying the socket name (defaulting to $SSH_AUTH_SOCK
, if set) along with the reuse option, we ensure that only a single running copy of ssh-pageant (per user) is required. Otherwise a separate incarnation would be launched every time Git Bash is invoked.
Now start a new Git Bash session, or source the profile edited just above, and run the ssh-add -l
command. If all is well, and Pageant is running (with one or more keys loaded), you should see something similar to the following.
$ ssh-add -l
4096 SHA256:XjN/glikgdBoBclg4EaN8sJ/ibrxTq7zVydpkUwANzk Heinz Doofenshmirtz (RSA)
If you use Git from Git CMD, or directly from the Windows command prompt, then you'll probably want to ensure that ssh-pageant is launched automatically at logon time. The start-ssh-pageant.cmd script is provided for this purpose, which resides in the cmd subdirectory of your Git installation.
Unlike the Git Bash case above, this scenario requires the SSH_AUTH_SOCK environment variable to be set before running the script... otherwise it will simply exit without performing any action. This is normally configured as a persistent USER variable, with the value specifying the desired socket file path in Unix/MSYS2 format.
NOTE: Since there can only be a single global variable of a given name, this approach may or may not cause conflicts if you have multiple environments which utilize the SSH_AUTH_SOCK setting. Running Git alongside of Cygwin, or MSYS2, for example. One way to address this is to use a fully-qualified Windows path for the socket instead of an environment-specific Unix/MSYS2 path.
Launch the Control Panel, and then select System followed by Advanced system settings. Click on the Environment Variables button, and finally New... in the User variables (not System variables) section. Enter SSH_AUTH_SOCK for Variable name and /tmp/.ssh-pageant-%USERNAME% for Variable value, then click OK.
Now launch a new Git CMD or Windows command prompt (pre-existing sessions won't see the new variable), and enter the command set SSH_AUTH_SOCK
. If all went according to plan, you should see something similar to the following.
C:\Users\heinz.doofenshmirtz> set SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/.ssh-pageant-heinz.doofenshmirtz
NOTE: the cross-environment-compatible (git for windows, msys2, and cygwin) equivalent would require a fully qualified windows path like C:\Users\MYUSERNAME\AppData\Local\Temp\.ssh-pageant-MYUSERNAME
. The correct value can be determined by running a command like cygpath --windows /tmp/.ssh-pageant-%USERNAME%
in a Git Bash window.
At this point you should run start-ssh-pageant.cmd manually, in order to verify that the agent starts successfully. Assuming that Git is installed into C:\Program Files\Git, this should look something like:
C:\Program Files\Git\cmd> start-ssh-pageant
Starting ssh-pageant...
SSH_AUTH_SOCK='/tmp/.ssh-pageant-heinz.doofenshmirtz'
SSH_PAGEANT_PID=11444
Assuming that the relevant keys have been loaded into Pageant, you should now be able to perform Git operations which rely upon them using OpenSSH without being prompted for the passphrase.
The most common approach is to create a shortcut pointing to start-ssh-pageant.cmd, and place it in your startup folder (Start Menu / Programs / Startup). Once in place, it should be launched automatically when you logon to Windows and be available to all Git processes.
Since ssh-pageant (like ssh-agent) is intended to bypass the requirement to repeatedly enter your private key password, it's imperative that its socket file be private in order to use it safely. In other words, you want to be extremely careful on multi-user systems to ensure that the SSH_AUTH_SOCK file -- and preferably the directory which includes it -- isn't accessible to anyone else. For a normal Git for Windows configuration this shouldn't be an issue, as /tmp is normally mapped to a private location under your Windows user profile.
Effectivement il est possible pour chaque type de document de definir la maniere dont git va faire le diff et cela afin de pouvoir "voir" les vrais differences.
bonne idee je la garde de cote.
I fixed this issue for several of my colleagues by running the following two commands:
git config --global url."https://github.com/".insteadOf git@github.com:
git config --global url."https://".insteadOf git://
One thing we noticed is that the .gitconfig used is not always the one expected so if you are on a machine that modified the home path to a shared drive, you need to ensure that your .gitconfig is the same on both your shared drive and in c:\users[your user]\
Un article sur le fait qu'il ne faut pas faire trop de branche en GIT...
Je pense surtout que l'auteur fait des pull au lieu de fetch/rebase
et ne connait pas le rebase avant push
ni le fait que l'on peut réécrire l'historique ou même grouper des commits.
mais effectivement avec le fonctionnement "de base" il vaut mieux se limiter...
Voir aussi http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
Le site de tutoriel pour GIT
Tout un tas de choses à faire quand vous avez fait une erreur avec git
Merci pour le poisson ;) je vais tester cela de suite :
1er article d'une série qui propose une alternative plus simple/fiable/rapide au Maven Release Plugin de Jenkins pour créer une nouvelle release Maven.
https://axelfontaine.com/blog/maven-releases-steroids-2.html
https://axelfontaine.com/blog/maven-releases-steroids-3.html
https://axelfontaine.com/blog/final-nail.html
The Multi Module Maven Release Plugin for Git
This plugin is an alternative to the maven-release-plugin which was created with the following principles:
It should be trivial to release modules from a multi-module plugin, and only those modules that have changes should be released
No commits should be made to a repo during a release
Maven conventions such as developing against SNAPSHOT versions should be retained
Git should not need to be installed on the system.
See the introductory blog post for more background.
The plugin works with the idea that a software module has two types of versions: the “business version” and the “build number”. The business version is used for semantic versioning, and may be something like “1.0”, “1.1.0”, etc. During development, the version in the pom is the business version with -SNAPSHOT appended. During a release, module version becomes business-version.build-number and this is what the repo is tagged with, and this is what the pom version becomes in the deployed artifact (however this version is not committed as a change to your pom).
This plugin automatically generates build numbers, starting from 0 and incrementing each time, by looking at previous releases in the Git history. Alternatively, you can use a number that increments on each release - like your CI server’s build number for example.
Differences with the maven-release-plugin
Only Git is supported
Each module released will have a separate tag with its artifact ID and version so that it is easy to see when a version of a module was released
A module is only released if there are changes to it
The release version of the pom is not committed back to the repository
Tests are run once by default (or optionally not at all)
Le dépôt GIT de Citadel un serveur de mail / xmpp / groupware codé en c/c++
très simple à installer et administrer.
je vous le recommande.
Merci pour ce partage, cela va mettre très utile ;)
The seven rules of a great git commit message
A properly formed git commit subject line should always be able to complete the following sentence:
If applied, this commit will your subject line here
ex : If applied, this commit will Fix bug with Y
-- chris.beams.io
La nouvelle version de GoGS est sortie !
Avec celle ci pas mal de correction et d'amélioration.
Pour pouvoir mettre à jour, si comme moi vous avez installé avec cette procédure:
http://gogs.io/docs/installation/install_from_source.html
il vous suffit de vous connecter avec l'utilisateur git.
sudo su git
puis de mettre à jour le package:
$ go get -u github.com/gogits/gogs
$ cd $GOPATH/src/github.com/gogits/gogs
$ go build
et une fois cela fait on redémarre le service.
Dans mon cas j'ai du killer le su qui a démarrer GoGS et ensuite le redémarrer à coup de
service gogs start
et voila en bas de page vous verrez v0.6.3
Très utile pour faire des changements sur les conf serveurs sans avoir de puppets.
Un article sur comment gérer de multiple équipe agile (ou une trés grosse....)
de bonne idée.
et la version readityourself:
http://latest.readityourself.net/readityourself.php?&url=http%3A%2F%2Fwww.infoq.com%2Farticles%2Fagile-version-control
http://tilap.net/gitliste-des-commandes-a-connaitre/
http://pioupioum.fr/developpement/git-10-commandes-utiles.html
http://putaindecode.fr/posts/git/boutez-les-bugs-domptez-votre-historique/
http://www.yterium.net/GIT-c-est-facile-2
https://git-scm.com/book/fr/v1/Les-bases-de-Git-Visualiser-l-historique-des-validations
Comment installer Gogs, un "github/gitlab" like en go
fonctionne bien avec un VPS debian d'OVH.
Apprendre GIT par l'exemple ?
voici un TRES BON tutoriel !
vraiment sympa et bien expliqué!