Open-source News

What Git aliases are in your .bashrc?

opensource.com - Tue, 04/05/2022 - 15:00
What Git aliases are in your .bashrc? AmyJune Hineline Tue, 04/05/2022 - 03:00 Up Register or Login to like.

Many open source users love a good Bash alias and are usually happy to show off a particularly robust .bashrc file when given the chance. If you're a frequent user of Git, you might benefit from a few Git aliases mixed in with your other Bash aliases. Alternately, you can create aliases specific to Git with this git config command. This example sets the git co command to git checkout.

$ git config --global alias.co checkout

I asked our contributors for their favorite and most useful Git aliases so that you could take advantage of their ideas. Here are their suggestions.

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Aliases

Here's an easy way to see just the most recent log entry:

git config alias.last 'log -1 HEAD'

Opensource.com author Sachin Patil uses hist for reviewing logs:

log --pretty=format:'%h %ai [%an] %s%d' --graph

Sachin creates this Bash alias for pull requests:

# github pull request. 
# Usage: git pr

pr="\!sh -c 'git fetch $1 pull/$2/head:$3 && git checkout $3' -"

The git diff command is helpful for all kinds of comparisons, but sometimes all you really want is the file name of what's changed. Kristen Pol creates an alias to shorten the --name-only option:

git diff --name-only

Kristen says, "We typically have a lot of development happening simultaneously, so knowing the most recent commit across all branches is handy." Here's a command Kristen aliases for that purpose:

git branch --remotes --verbose --sort=-committerdate

Everybody appreciates a fresh start. This is Kristen's alias for wiping out a branch, leaving it fresh and clean:

alias gitsuperclean='git reset --hard; git clean --force -d -x'Custom filter-repo command

Chris has been using a "third-party" Git command called git-filter-repo.

Chris explains the alias. "Ever want to pull a specific directory out of a larger Git repository and make it its own, separate repo, while keeping all the Git history? That's exactly what filter-repo does."

Your aliases

What Git command do you use so often that you alias it? Do you use Bash aliases or Git aliases, or a mix of both? Tell us in the comments!

I asked our contributors for their favorite and most useful Git aliases so that you could take advantage of their ideas.

Image by:

kris krüg

Git What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

My guide to understanding Git rebase -i

opensource.com - Tue, 04/05/2022 - 15:00
My guide to understanding Git rebase -i Vaishnavi R Tue, 04/05/2022 - 03:00 Up Register or Login to like.

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. It is an essential tool in an open source developer's toolkit.

This article covers why and how to use the git rebase --interactive (-i for short) command. This is considered an intermediate Git command, but it can be very useful once you start working with large teams.

This command is one of the most powerful in Git. The git rebase command helps you manage multiple commits, including:

  • Flatten (or squash in Git terminology) several commits so that they look like they were all done at once
  • Delete one of the commits
  • Split one commit into two
  • Reorder the commits

Yes, the git rebase command can rewrite your repository's commit history by rearranging, modifying, and even deleting commits. So let's get started!

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Helpful instructions in the rebase message

The git rebase -i interface is, as its long form --interactive flag implies, an interactive interface. It provides a list of commits, and then you choose what actions you want Git to take on each of them. Taking no action is a valid choice, but at least one commit must be marked as the one to squash, or the rebase is functionally meaningless.

  • p, pick — Pick this commit to keep.
  • e, edit — Edit this commit to amend the commit message.
  • r, reword — Use this commit, but also edit it.
  • s, squash — Squash this commit into a previous commit. When performing a git rebase -i, you must have at least one commit marked as squash.
  • d, drop — Delete this commit.
Squashing commits

Suppose you have two commits, and you want to squash them into one. This is achieved by using git rebase -i HEAD~2 (that's two commits from your current position) command and by putting the word squash before the commit.

$ git rebase --interactive HEAD~2

Running this command gives you a list of commits in your text editor that looks something like this:

pick 718710d Commit1.
pick d66e267 Commit2.

If you want to make a single commit from two commits, then you have to modify the script to look this:

pick 718710d Commit1.
squash d66e267 Commit2.

Finally, save and exit the editor. After that, Git applies all the changes and opens an editor to merge the two commits:

# This is a combination of 2 commits.
# This is the 1st commit message:

Fuse smoke test versioning.

# This is the commit message #2:

Updated the code.

# Please enter the commit message for your changes.

Saving this results a single commit that introduces the changes of two previous commits.

Reordering commits

Suppose you have three commits, and you want to change their order such that Commit3 is first, Commit2 is second, and then third is Commit1. Run git rebase -i HEAD~3 to make this happen:

$ git rebase --interactive HEAD~3

This script is opened in your editor:

pick 8cfd1c4 Commit1
pick 718710d Commit2
pick d77e267 Commit3

Modify the script like this:

pick d77e267 Commit3
pick 718710d Commit2
pick 8cfd1c4 Commit1

When you save and exit the editor, Git rewinds your branch to the parent of these commits, and applies d77e267, then 718710d, and then 8cfd1c4 as the commit numbers are not matching.

Delete a commit

Suppose you have two commits and want to get rid of the second one. You can delete it using the git rebase -i script.

$ git rebase -i HEAD~2

This script is opened in your editor:

pick 8cfd1c4 Commit1
pick 718710d Commit2

Place the word drop before the commit you want to delete, or you can just delete that line from the rebase script.

pick 8cfd1c4 Commit1
drop 718710d Commit2

Then save and exit the editor. Git applies the changes and deletes that commit.

This can cause merge conflicts if you have many commits later in the sequence that depend on the one you just deleted, so use it carefully. But you have an option to revert the changes.

Rebase with caution

If you get partway through a rebase and decide it's not a good idea, use the git rebase --abort command to revert all the changes you did. If you have finished a rebase and decide it's wrong or not what you want, you can use git reflog to recover an earlier version of your branch.

Rebasing is powerful and can be useful to keep your repo organized and your history clean. Some developers like to rebase the main branch so that the commits tell a clear story of development, while others prefer for all commits to be preserved exactly as they were proposed for merging from other branches. As long as you think through what your repo needs and how a rebase might affect it, the git rebase command and the git rebase -i interface are useful commands.

The git rebase command is one of the most powerful in Git. It can rewrite your repository's commit history by rearranging, modifying, and even deleting commits.

Image by:

Image from Unsplash.com, Creative Commons Zero 

Git What to read next How to reset, revert, and return to previous states in Git This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Installation and Review of Q4OS Linux [Lightweight Distro]

Tecmint - Tue, 04/05/2022 - 12:06
The post Installation and Review of Q4OS Linux [Lightweight Distro] first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

Q4OS is a new Linux distribution that’s based on Debian; a common base that’s shared with other distributions like Ubuntu and Linux Mint. It’s aimed at users who just want a simple, stable, easy

The post Installation and Review of Q4OS Linux [Lightweight Distro] first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

CentOS Hyperscale SIG Updates systemd & Linux Build, Eyeing Btrfs Transactional Updates

Phoronix - Tue, 04/05/2022 - 07:19
Formed last year was the CentOS Hyperscale SIG for back-porting major package versions and other features back to CentOS and other interesting features for modern enterprise environments...

GNOME's Nautilus Could See Big Improvements, New Image Viewer Coming Into Focus

Phoronix - Tue, 04/05/2022 - 06:19
GNOME developer Chris Davis has laid out plans for at least some of the work items he and other open-source developers hope to accomplish for GNOME 43 and future releases...

Fedora Workstation Brainstorming A Possible GUI-Based Linux Recovery Environment

Phoronix - Tue, 04/05/2022 - 01:50
When it comes to system recovery on Linux, users are most often only left with a command-line for trying to recover from a failed kernel boot, borked boot loader configuration, or other show-stopping problems. With Fedora Workstation right now they have only their CLI-based Linux recovery process but are eyeing the possibility of creating a complementary GUI-based recovery environment...

Question from the New Guy!

The Linux Foundation - Tue, 04/05/2022 - 01:43

“Here’s a question from the new guy”. I have been using this a lot the past few weeks after starting here at the Linux Foundation as the lead editor and content manager. How long can I pull that off? 

The reality is that I am new to working professionally in open source software – and really the software/technology industry. But, it has been a long time passion of mine. I spent my formative years in the 1980s and had a drive to learn to program computers. When I was 12, I asked my mom for a computer. Her response, “you have to learn to type first”. 

I went to the library, checked out typing books, and taught myself on our electronic typewriter. We couldn’t afford a computer, but I received a hand-me-down TI-994A and then a Commodore 64 with a tape drive. I taught myself BASIC and also dialed into bulletin board systems (BBS) at a mind-blowing 300bps. If you have never experienced 300bps, imagine yourself reading at 10% of your normal pace. 

I mention BBSs because, in many ways, they were the precursor to open source software. Someone dedicated their PC and a phone line for others to dial in, share messages, exchange software, answer technical questions, etc. 

Fast forward a bit – I taught myself to code enough to get a couple of coding jobs in high school but ended up getting a business degree in college and then working in politics for 15+ years. My passion for software and technology didn’t lapse, but it was mostly a tech hobbyist – taking classes in front-end web development and writing a couple basic web apps, teaching myself some PHP, Python and WordPress development, and reading/writing about software development. And, for the record, I already had a GitHub repo before starting here. 

With that bit of background, let me say that I am very excited about working at the Linux Foundation and diving into the open source community. I am a self-driven, life-long learner, and I want to take you along my journey here to learn about what we do, all of our projects, what open source is, how to advance it, and more. 

At LF, we embrace what we call the three H’s: humble, helpful, and hopeful. It isn’t just lip service. I see it lived out every day, in every interaction I have with my coworkers. My goal with this journey is to be: 

  • Humble: There is so much I don’t know about the open source community and the LF. I am learning every day. 
  • Helpful: I want to be helpful by sharing what I am learning. Much you may already know, but some you may not.
  • Hopeful: My hope is two-fold: I hope others learn too; I am hopeful that our community will continue to grow and thrive and solve some of the world’s toughest challenges. 

The three H’s are perfectly aligned with the general culture of open source. One of the LF’s onboarding tasks for new employees is to take a class entitled Open Source 101. Within that class they teach us Ten Open Source Culture Cores: 

  1. Be open. Openness breeds authenticity. Be consistently authentic in all of your work. 
  2. Be pragmatic. Action > talk. Work towards measurable value, not obscure, abstract, or irrelevant ideas. (Side note: when I worked in politics, my go-to line when speaking to groups was that I was a bit of an anomaly in Washington, I was long on action and short of talk.) 
  3. Be personal. Always focus on a personal level of service and interaction. People don’t join open source communities to talk to computers. 
  4. Be positive. Highly positive environments generate positive engagement.
  5. Be collaborative. Involve people, gather their feedback, get a gut check, and validate your ideas. The only problem silos solve is how to store grain. 
  6. Be a leader. Be open and collaborative–focus on the other 9 Culture Cores too. 
  7. Be a role model. Be the person you want to be and you will be the leader other people want you to be. 
  8. Be empathetic. Don’t just be empathetic in the privacy of your own mind. Say it, demonstrate it visibly. This all builds trust. Empathy is a powerful driver for building inclusion, which is a powerful driver for innovation.
  9. Be down-to-earth. Leave your ego at the door. 
  10. Be imperfect. We all make mistakes. Acknowledge them, share them, and learn from them. 

What a great synopsis of the culture of open source technology. 

With that, let me close out this week by first stating the obvious – a lot has transpired in technology since my first TI-994A (never mind the fact that my network speed is literally one million times faster). I hope you will join me on my “Questions from the New Guy” journey. Look for weekly-ish blog posts diving into all aspects of The Linux Foundation, our projects, and open source technology. 

The post Question from the New Guy! appeared first on Linux Foundation.

Pages