Welcome to another VSHN.timer! Every Monday, 5 links related to Kubernetes, OpenShift, CI / CD, and DevOps; all stuff coming out of our own chat system, making us think, laugh, or simply work better.
This week we’re going to talk about the latest news of that other project named after Linus.
1. Git users are familiar with those typical 40 hex character-long hashes generated by Git, uniquely identifying a commit across time and space. Uniquely? Well, to a certain extent. Since the beginnings Git generates those hashes using the SHA-1 hashing algorithm, but a few years ago researchers found a way to break it. Since then, the Git project maintainers have started a transition towards SHA-256. Git version 2.29, released only a few weeks ago, is the first one implementing experimental support for this new hashing algorithm: try it out with
git init --object-format=sha256 repo. Be aware of the experimental word before you start using it in production, though.
2. Inexperienced users of Git might inadvertently deploy their applications to production servers together with the
.git folder, the one that contains the whole history of your Git repo. Yes, the same one including all the stuff you once wrote and the deleted, like passwords and security keys, because Git never forgets anything. And, lo and behold, curious and entrepreneurial researchers have found those folders all over the place, and of course, started downloading them, and examining their contents, many of which were, of course, confidential. Another case of severe DevOooops. Now you can do that too, thanks to Gitjacker.
3. For a long time big firms have been reluctant to adopt open source software and DevOps practices, justifying those decisions on arguments of trade secrecy and security. But the competition is stronger than ever, and even the biggest of banks in the Paradeplatz are ready to jump on the train. Take for example the case of UBS, now actively using GitLab to help their teams release better software to their users, and more often than ever. (Article in German.)
4. Have you heard of
git summarize-subtree? It is the Git command that summarizes all applied subtrees outside the format-patched non-failed applied archives. What about
git split-ref? It is used to split any non-applied upstream refs over various bundled remote indices, which can happen whenever
git manufacture-head manufactures the non-pushed local heads outside some stashed subtrees, and the
--nick-race-upstream diffs a ref for the subtree that is bundled by a staged stash. Excuse me, what? How can one keep up with so many Git commands and options? Fear not, the previous examples come from the fake Git man page generator! For reference of actual Git commands, you might want to refer to Dangit, Git!?! instead.
5. The tool of the week is GOMP, the Git cOMPare tool, a nice app written in Python to compare Git branches in the command line. A great way to prepare releases and fixing conflicts!
How much does your team depend on Git? Are you using some other SCM tool? Would you like to share any pro Git tip with our readers? Get in touch with us through the form at the bottom of this page, and see you next week for another edition of VSHN.timer.
PS: would you like to receive VSHN.timer every Monday in your inbox? Sign up for our weekly VSHN.timer newsletter!
PS2: would you like to watch VSHN.timer on YouTube? Subscribe to our channel vshn.tv and give a thumbs up to our videos!
PS3: check out our previous VSHN.timer editions about Git: #48 and #10!