• New feature in Git 3: closures

    • Translation

    Git is a popular version control system. In Git, an atomic change of one or several files is called a commit, and several consecutive commits are combined into a branch. Branches are used to implement new ideas (features).

    It happens that the idea is a dead end and the developer has turned the wrong way, so he needs to roll back to the original version. He should forget about the new branch, switch to the main dev or master branch and continue working. In this case, the "scion" will hang forever, as well as the desire to remove it. But how to remove the part of the history? This branch shows the efforts of the hard-working programmer, even if in vain. So it will be easier to report to the boss, because an unsuccessful result is also a result!

    I hasten to rejoice that Git developers are going to introduce a new command to close such "homeless" branches in the third version. The current version is 2.21.0.

    How to use this command, what benefits does it give and what do IT companies think? The article answers these and other questions.

    Read more →
  • How to vendor a git into another git

      Discovering git vendor extension.

      Cross-post from my medium blog: https://medium.com/opsops/git-vendor-295db4bcec3a

      I would like to introduce the proper way to handle vendoring of git repositories.

      What is is ‘vendoring’?

      Vendoring is a way to integrate other’s work into your own. It’s the opposite of ‘linking’ against third-party library. Instead of having that library as a dependency, application uses this library as a part of own source code and keep that code ‘inside’ itself.

      Normally, vendoring is done by language tooling: bundler, cargo, pip, etc. But sometimes you need to vendor something not covered by any existing toolset, or something multi-language, that it’s impossible to find the ‘core’ language tool for that.

      The solution for this situation is vendoring on a git level. You have your own git repository (I call it ‘destination repo’), and you want to incorporate some other repository (I call it ‘source repo’) as a directory into your (destination repo).

      The things you expect from a well-designed vendoring system (regardless of Git it is or not):

      • Visibility. You want to know that some code is vendored, means it wasn’t written by committer.
      Read more →