Tag Archives: Git

Compiling Git on CentOS 6

I recently had the need to compile Git on a CentOS 6 system, because the available version (v1.7.1) did not support the ls-remote command used  by the Jenkins Git plugin. The various posts I found via Google were missing a crucial prerequisite, hence this short post.

  • Uninstall old Git with
    yum remove git
  • Install required packages (for me!) with
    sudo yum install libcurl-devel zlib-devel asciidoc openssl-devel xmlto
    
  • Download source code from https://www.kernel.org/pub/software/scm/git
  • Extract source with
    gzip -dc <FILE> | tar -xvf -
  • Compilation and installation
    make configure
    ./configure --prefix=/usr
    make all
    sudo make install install-doc install-html

And that should be it.

Visual Studio Code and Bash on Windows

A while ago I started using Visual Studio Code and it is a great tool for many things. Primary use-cases for me are Chef recipes and SFDX at the moment, for both of which there are extensions in the VS Code marketplace. Also, I like to use Bash (the one that came with Git for Windows) in the terminal .

But at least on Windows (this seems to be different on Mac OS) some of the standard keyboard shortcuts for Bash are used by VS Code itself. Relevant for me personally were Ctrl-A, Ctrl-E, and Ctrl-K. To make bash usable for me, I had to “undefine” those shortcuts in VS Code, but only for the terminal.

Here are the necessary additions to  keybindings.json :

// Place your key bindings in this file to overwrite the defaults

[
 { "key": "ctrl+a",
   "command": "",
   "when": "terminalFocus" },
 { "key": "ctrl+e",
   "command": "",
   "when": "terminalFocus" },
 { "key": "ctrl+k",
   "command": "",
   "when": "terminalFocus" },
]
Hope that helps!

Version Control Systems and other Repositories

Recently, a few colleagues and I had a very interesting discussion about what should go into a Version Control System (VCS) and what should not. In particular we were arguing as to whether things like documents or project plans should go in. Here are a few things that I came up with in that context.

I guess the usage of VCS (and other repositories) somehow comes down to a few general desires (aka use-cases):

  • Single source of truth
  • History/time machine
  • Traceability
  • Collaboration
  • Automation of builds etc.

In today’s world with its many different repositories you can either go for a mix (best-of-breed) or the lowest common denominator which is usually the VCS. So what’s stopping people from doing it properly (=best of breed)?

  • Lack of conceptual understanding:
    • Most people involved in those kinds of discussion usually come from a (Java) development background. So there is a “natural” tendency to think VCS. What this leaves out is that other repositories, which are often DB-based, offer additional capabilities. In particular there are all sorts of cross checks and other constraints which are being enforced. Also, given their underlying architecture, they are usually easier to integrate with in therms of process-driven approaches.
    • Non-technical folks are mostly used to do versioning-by-filename and require education to see the need for more.
  • Lack of repository integration: Interdependent artefacts spread over multiple repositories require interaction, esp. synchronisation. Unless some kind of standard has emerged, it is a tedious task to do custom development for these kinds of interfaces. Interestingly, this goes back to my post about ALM needing middleware.
  • Different repositories have clients working fundamentally differently, both in terms of UI and underlying workflow (the latter is less obvious but far-reaching in consequence). Trying to understand all this is really hard. BTW: This already starts with different VCS! As an example just compare SVN, TFS and Git (complexity increasing in that order, too) and have “fun”.
  • Lack of process: Multiple repositories asking for interaction between themselves also means that there is, at least implicitly, a process behind all this. Admittedly, there is also a process behind a VCS-only approach, but it’s less obvious and its evolvement often ad-hoc in nature. With multiple repositories a more coordinated approach is required to the process development, also because often this means crossing organisational boundaries.

Overall, this means that there is considerable work to be done in this area. I will continue to post my ideas here and look forward to your comments!

Git Links

Here is a number of links to resources I found useful.

Using Git without Shell Access

If you want to host a Git repository there should normally be no shell access for all the people that need access to the repositories. So far many people have used gitosis to achieve this. Now there is a “new kid on the block”, called gitolite. I have not really used it in practice so far, but the added functionality looks promising and I also like the fact that it’s written in Perl. There is also a chapter about it in the Pro Git book.

Scripts for gitosis

gitosis is a nice program for hosting git repositories without having to give regular access to users. Using SSH under the covers, it basically acts as a special shell, thus limiting access to git. There are a number of nice tutorials available that explain how to make things work. I particularly liked this one. However, there is a lot of manual steps involved and a lot of errors can happen. I have therefore spent some time and started writing a few shell scripts that provide a more comfortable interface. At the moment the following scripts exist:

  • gitosis-init.sh : Initializes gitosis and “installs” a regular user (not git or gitosis) for further admin work. This needs to be executed locally on the machine that runs gitosis. In order to avoid password hazzle, it is recommended to run it as root. Alternatively you can run it as the gitosis user. However, this mode has not been tested well so far. Any feedback is highly welcome.
  • gitosis-add-repo.sh : Puts an existing local git repository into a remote gitosis repository.

The following scripts are currently planned for the future (other ideas are welcome!):

  • Add user to gitosis (copy SSH public key over)
  • Add user to repo (read/write access)

Download: gitosis-scripts.tgz

Please note that the scripts were written on Debian Lenny (v5) and so far only tested on this system. For more detailed instructions please check out the man pages (also included in the scripts).

[Update 2010-01-03: You may also want to check on gitolite, which is a gitosis rewrite in Perl with far more granular access control.]