DEV Community: Ayush Poddar

Practically evaluate your system's performance - Look beyond time complexity

Ayush Poddar — Fri, 10 May 2024 06:00:03 +0000

Time complexity is a common parameter used to describe the performance of an algorithm. They tell us about the performance of an algorithm in terms of the size of the input. In other words, time complexity is a measure of the affect of input size on performance.

Consider an algorithm such as linear search on an unordered list of numbers (linear time complexity). The time taken by this algorithm increases linearly with the size of the input.

Time complexity is useful for a theoretical analysis on the performance of an algorithm. However, in the real world, our programs run on many layers of abstraction which introduce their own complexities and optimisations that are hard to account for in terms of mathematical equations or theoretical concepts.

Real world data have special constraints which, in combination with the above-mentioned complexities and optimisations, may result in a theoretical worse algorithm to perform better. Apart from this, practically, we are often happy with good enough solutions that works for 99% of the cases in the real world. Many systems are built such that their accuracy is traded-off in favour of a performance boost.

Example

Most modern CPUs optimise the performance of our programs by pre-calculating the results of the operations that are yet to be executed in our coding programs. However, when these programs utilise conditionals (like if-else statements), there are chances of the pre-calculations occurring on the incorrect branch. This leads to a wastage of CPU cycles as the pre-calculations are performed on the wrong branch, affecting our systems’ performance.

The aim of this post is to encourage you to think beyond the time complexity calculations when evaluating your systems’ performance, and corroborate your knowledge of time complexity by benchmarking with real world data in the real world-like environment.

Demonstration

Consider this common leetcode problem: Climbing Stairs. The problem statement goes something like this:

There are n steps in a staircase. You can take either 1, 2, or 3 steps at a time. In how many distinct ways can you climb the stairs?¹

The solution to this problem is straight-forward. The aim of this post is not to discuss the correct solution but rather discuss the importance of evaluating the solution beyond the asymptotic analysis, i.e., the time and space complexity. The best solution to this problem has a linear time complexity and a constant space complexity. But I will be analysing the approach where the time complexity is in the order of $O(2^n))$ , since it will best demonstrate the importance of benchmarking by comparing similar algorithms with similar time complexity.

Building the solution(s)

As an example consider a staircase with 5 steps (n = 5).

"Stairing" into the abyss

From the initial position, you can either go to step 1 or step 2 or step 3.

The first step (or leap)

Essentially, now the problems breaks down into the sum of three sub-problems:

Number of ways you can get to step 5 from step 1. Or, the number of ways you can climb a 4-step staircase (n = 4).
Number of ways you can get to step 5 from step 2. Or, the number of ways you can climb a 3-step staircase (n = 3).
Number of ways you can get to step 5 from step 3. Or, the number of ways you can climb a 2-step staircase (n = 2).

Mathematically speaking, if the function $f (n)$ is defined as the number of ways you can climb a staircase of $n$ steps, then:

f (n) = f (n - 1) + f (n - 2) + f (n - 3)

A straight-forward code implementation for the same is:

def recursiveSolution(n):
    if n <= 2:
        # When n = 0, 1, 2; return 1, 1, 2 respectively.
        # You can climb a 0 or 1 step staircase in only one way
        # and climb a 2-step staircase in 2 ways ((1, 1) and (2))
        return (1, 1, 2)[n]
    return recursiveSolution(n - 1) + recursiveSolution(n - 2) + recursiveSolution(n - 3)

Tree based approach

Another way that this problem can be approached is by thinking in terms of a tree, where each node of the tree represents your current position on the staircase. There are three possible children from each node, one of every step you can take from your current position.

The tree representation (Download)

Next, you can find all the possible paths to the desired node (position). Each node (position) can be represented by a number, which represents your current position on the staircase. Initially, you start with position = 0 and you need to find all possible paths to position = n (position = 5 in this case).

Tree. Nodes represented as number

This turns into a classic graph/tree problem, which you can solve either by performing a breadth-first search (BFS) or depth-first search (DFS). Implementing a depth-first search would basically replicate the recursive solution implemented earlier, with the only difference being that you would be manually managing the stack, instead of the program managing the stack in the form of call stack. The python implementation of a DFS solution would be:

from collections import deque

def graphDFS(n):
    stack = deque()
    stack.append(0)  # start with position = 0
    count = 0
    while stack:
        x = stack.pop()  # get next position to evaluate
        if n - x <= 2:  # if current position is 0 or 1 or 2
            count += (1, 1, 2)[n - x]  # just add to count
            continue  # further evaluation not needed
        # Append the children to the stack
        stack.append(x + 1)
        stack.append(x + 2)
        stack.append(x + 3)
    return count

The core logic of the recursiveSolution function has been replicated as-it-is to ensure that both functions are as equivalent as possible. The breadth-first version of the solution would be:

from collections import deque

def graphBFS(n):
    count = 0
    queue = deque()
    queue.append(0)  # start with position = 0
    while queue:
        x = queue.popleft()  # get next position to evaluate
        if n - x <= 2:  # if current position is 0 or 1 or 2
            count += (1, 1, 2)[n - x]  # just add to count
            continue  # further evaluation not needed
        # Push the children to the queue
        queue.append(x + 1)
        queue.append(x + 2)
        queue.append(x + 3)
    return count

The two functions are the same except for the usage of stack in one and queue on another. The time complexity of all the three functions is $O(2 ^n))$ .

This post assumes that you know how to calculate time complexity. Hence, it does not cover the calculation of the time complexity.

Performance analysis

To benchmark the performance of each of the above functions, I wrote a script that called each function from n = 1 to n = 20 and repeated this x times (called runs). Essentially, I wanted to find the total time taken by a function if it is called for all values between n = 1 and n = 20. The script looks like this:

import time

# Helper function to measure runtime
def measure_runtime(func, n):
    start_time = time.perf_counter()
    result = func(n)
    end_time = time.perf_counter()
    return end_time - start_time, result


function_timings = {}
functions = [recursiveSolution, graphBFS, graphDFS]
times = [0 for _ in functions]  # to store the running times corresponding to each function
runs = 10000  # number of times to repeat the benchmarking => 10, 100, 1000, 10000

for _ in range(runs):
    for n in range(20):  # Test for n = 1 to n = 20
        for i in range(len(functions)):
            func = functions[i]
            time_taken, _ = measure_runtime(func, n)
            times[i] += time_taken

for i in range(len(functions)):
    func = functions[i]
    # Average running time per run
    function_timings[func.__name__] = times[i] / runs

The results shown below is the average execution time per “run”. In other words, each bar shows the total execution time for a function for all values of n from 1 to 20.

As can be seen, clearly the recursiveSolution function is the fastest. The next fastest function is the graphBFS function, which is approximately ~40% slower than recursiveSolution function.

Note

I found it intriguing that graphDFS is the slowest one (even if by a small margin). graphDFS is fundamentally closer to recursiveSolution since both of them use a stack to gather the results.

Thoughts

All the three functions have the same time complexity. All of them essentially implement the same logic. All of them return/continue when number of steps left is less than or equal to 2 (<= 2). Yet, there is a ~40% difference in their performances.

The analysis above aptly demonstrates that equivalent time complexity or algorithmic logic does not necessarily imply equivalent system performance. It is necessary to benchmark the functions/systems we implement to be able to accurately comment on their performance.

However, it would be impractical to benchmark every bit of code we write. The decision on whether or not to benchmark is a judgement call that improves as we learn more about the hidden layers of abstraction in our systems. With knowledge and experience, we can make better judgement on whether or not we use time complexity as the sole metric to gauge the performance of our systems. For example, in almost all cases, binary search would be better than linear search on a sorted list of numbers.

Bonus: Best solution to this problem

The solution to the Climbing Stairs problem that runs in linear time complexity is:

def linear(n):
    a, b, c = 1, 1, 2
    for _ in range(n):
        a, b, c = b, c, a + b + c
    return a

Note

The solution is similar to the solution for getting the nth number in the Fibonacci sequence.

I encourage you to try out different solutions (all of which execute in linear time complexity) and compare their performances. You can compare the above function with this one:

def linear2(n):
    if n == 1:
        return 1
    dp = [0 for _ in range(n + 1)]
    dp[1] = 1
    dp[2] = 2
    for i in range(3, n + 1):
        dp[i] = dp[i - 1] + dp[i - 2] + dp[i - 3]
    return dp[n]

Think about more ways to achieve the same result in linear time complexity and compare their performances.

References

CS Primer - Staircase ascent problem → I recommended this course for experienced software engineers who are looking to learn more about the foundational computer science concepts.
CS Primer - Seminar on analysing systems

Footnotes

Leetcode presents a variant of this problem where you can take only 1 or 2 steps at a time. ↩

Magical Git when creating a branch off a remote branch

Ayush Poddar — Thu, 24 Aug 2023 19:20:25 +0000

This post is part of my "Shorts" series, where each post is concise and hyper-focused on a single concept.

Imagine that you clone a Git repository with many branches. After the clone is successful, if you run git branch, you'd see that you only have the main branch in your local repository. However, the command git branch --all will output a list of branches prefixed by remotes/origin/. Here is the top 5 lines of the output when running this command on the discourse project.

* main
  remotes/origin/0-ansible-eggs
  remotes/origin/0-app-events-revolution
  remotes/origin/0-array-lint
  remotes/origin/0-assets-spec

Assuming that you want to switch to the 0-ansible-eggs branch, you can run the following command:

git checkout 0-ansible-eggs

If you have read my earlier post on Git branches, you'd know that git checkout can be used to switch to an existing branch, not to an non-existent branch. As already mentioned above, 0-ansible-eggs does not exist in your local repository.

In this post, I will be exploring the magic that Git performs in making this short command work.

Behind the scenes

Assume that you want to switch to the 0-ansible-eggs (remotes/origin/0-ansible-eggs) branch, but not with the same name. You may want to use a different name for the corresponding local branch, then the command that you'd use is:

git checkout -b <localBranchName> remotes/origin/0-ansible-eggs

The localBranchName can be any name, even the same name you hated initially: 0-ansible-eggs.

So, when you run git checkout 0-ansible-eggs and Git figures out that the branch 0-ansible-eggs does not exist (it is not present in local) AND this branch is present in only one remote, then Git will:

Automatically create the local branch with the same name
Set up tracking between the local branch and the remote branch
Switch to the local branch

In other words, Git expands git checkout 0-ansible-eggs into git checkout -b 0-ansible-eggs remotes/origin/0-ansible-eggs.

What did you learn in this post?

You learned how the commonly used git checkout command works behind the scenes even when the branch does not exist, in case of branches with the same name in remote.

Reference

https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

How to set a different Git branch name on remote

Ayush Poddar — Wed, 23 Aug 2023 19:54:40 +0000

This post is part of my "Shorts" series, where each post is concise and hyper-focused on a single concept.

Some software development teams - who use project management tools like JIRA - enforce conventions like naming your branches after the ticket IDs (e.g. T-1234). This practice helps create automated workflows and debugging. However, you might want a more descriptive branch name in your local development workflow (e.g. feat-user-auth).

In this post, we will be discussing how you can use different names for the same branch in your local and remote repositories.

How?

When we run the command git push origin branchName, under the hood, Git expands the command to git push origin branchName:branchName. This expanded command means that the local branch named "branchName" should be pushed to remote branch named "branchName".

So, using this as a hint, the way to use a different branch name in remote would be:

git push origin localBranchName:remoteBranchName

In the context of our example, the command would be:

git push origin feat-user-auth:T-1234

You could also add the --set-upstream flag to the command, so that you can directly run git push next time when trying to push the changes in feat-user-auth to its corresponding remote branch - T-1234.

Final words

When working in teams, having conventions for branch names is a very common practice. That does not mean that you should be losing your freedom to have your own custom branch names. Since now, you are in the position to have your own custom branch name while also following the conventions followed by your development team.

Reference

https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

Enhance the way you list Git branches with these 3 options

Ayush Poddar — Sun, 20 Aug 2023 17:44:59 +0000

This post is part of my "Shorts" series, where each post is concise and hyper-focused on a single concept.

As a developer, you may already be aware of the git branch command which is used to list all the branches in your repository. The sample output of a git branch command looks like this:

* color-hidden-files
  main
  show-abs-path-xargs
  size-in-bytes

Here, the asterisk (*) sign represents the current branch, i.e., the branch that the HEAD pointer points to.

In this short post, I intend to list some of the most used command line flags that can be used with the git branch command. These flags will help you:

View the last commit in each branch
List only merged/non-merged branches

View the last commit in each branch

If you use the --verbose (-v) flag, you can view the last commit in each branch. The sample output of running -v flag looks like this:

* color-hidden-files  305e248 refactor: split into two methods
  main                28c188b Merge pull request #594 from ayushpoddar/show-abs-path-xargs
  show-abs-path-xargs 44c370b Revert "version bump"
  size-in-bytes       5f3b880 spec fix: not more than 3 lines in the spec output

List only merged branches

If you want to see only those branches which have been merged into the current branch, then you need to use the --merged command line flag. The output of running the command with the --merged flag is similar to the output of a simple git branch command. However, it filters out all the branches whose work is pending to be merged into the current branch.

You can delete the branches whose commits have been merged into the current branch because the work done in those branches is available in the current branch.

List only non-merged branches

Similar to above, if you want to list only those branches that have some commits which are not part of the current branch, then you can use the --no-merged command line flag.

References

https://git-scm.com/book/en/v2/Git-Branching-Branch-Management

When (and more importantly why) are merge commits created?

Ayush Poddar — Sat, 19 Aug 2023 20:25:43 +0000

This post is part of my "Shorts" series, where each post is concise and hyper-focused on a single concept.

If you have worked with Git, you must have come across merge commits. These commits are not created every time you merge, but only on some special scenarios. In this post, we will learn about merge commits and when are they created. At the end of the post, I will also provide a way to avoid them.

First, the simple fast-forward merge

Consider that you have a branch named featureX which diverges from the main branch like shown below.

If you try to merge featureX into main using git merge featureX, you will see the text Fast-forward in the merge output. Git uses this merge strategy when the commit pointed to by the branch that is being merged into - main in this case - is a direct ancestor of the branch that is being merged - featureX in this case.

In other words, if you start following the parent starting from the commit pointed to by featureX and you reach the commit pointed to by main after some jumps, Git will simply move (fast-forward) the main branch pointer to the commit pointed to by featureX.

I have used the main branch as an example. I don't mean to convey that merges can only happen into the main branch. Any Git branch can be merged into any Git branch.

When the main branch is NOT an ancestor of your feature branch

Consider the scenario below where the main branch has moved ahead from the point where featureX diverged.

In this case, the commit pointed to by main is not an ancestor of the featureX branch. So, Git tries to find the common ancestor of the main and featureX. Then, Git performs a three-way merge between the common ancestor commit, the commit pointed to by main, and the commit pointed to by featureX. It creates a new snapshot that results from this merge and creates a "merge commit" on the main branch (or the branch being merged into).

A merge commit has more than one parent.

Avoiding merge commits

To avoid "merge commits", you can rebase the featureX branch on the main branch. After the rebase, the commit pointed to by main will become an ancestor of featureX. To learn more about rebasing, I suggest you read my post introducing git-rebase.

References

Did you know? A Git branch is essentially a 41-byte file

Ayush Poddar — Fri, 18 Aug 2023 18:57:23 +0000

Any semi-experienced developer would have used Git branches as part of their development workflow. They are very important for effective collaboration and isolating under-development code from production code. Developers often use branches to try out new ideas, tools, etc and then delete the branch once done. You would agree with me when I say that working with branches in Git is a breeze, so much so that most of us take this feature for granted and never stop to think about the underlying implementation or appreciate its lightweightness.

Most of us, who have never worked with any other version control system, will not be able to appreciate the ease of working with branches in Git. Older version control systems like Subversion usually took seconds or minutes (depending on the size of the repository) to create a new branch. On the other hand, creating a new branch in Git is almost instantaneous.

In this post, I am going to explore the inner implementation of branching in Git and help you figure out: How are branches in Git so lightweight?

Branches as pointers

In the previous post, we learned that commits in Git are simple objects with a reference to the snapshot of the code at the time of commit and a reference to the parent (previous commit).

Similarly, branches in Git are simple movable pointers that point to one of the commits. When you make a commit, the current branch's pointer automatically moves to the new commit.

There are no special properties associated with the main branch. It is just another branch that is created by default by Git for you to start working on.

Creating a new branch

When you create a new branch, a new pointer is created that points to the last commit made in the current branch. The following command creates a new branch called featureX:

git branch featureX

About HEAD

To know which branch you are currently on, Git maintains a special pointer called HEAD. It points to the current branch. In the figures above, you can see that HEAD is pointing to the main branch.

The command git branch <branchName> only creates a new branch but does not switch to it. To switch to the new branch, in this case featureX, you need to run:

git checkout featureX

As you can see in the figure below, switching to featureX moved the HEAD pointer.

You can create and switch to a new branch in a single command:
git checkout -b featureX

What happens when you make a commit now?

A new commit object is created and the featureX branch pointer moves to the new commit, along with the HEAD pointer.

Moving back to main

If you move back to the main branch now, the HEAD pointer will again point to the main branch, as shown below. Also, your files will be reverted to the snapshot that main points to.

If you make a new commit now, your project history will diverge. A new commit will be created which will be isolated from the commit you made in the featureX branch. The figure below should help you get a better understanding.

Commits in both branches are isolated from each other. Switching to a branch will revert your files to the snapshot that the branch points to.

As already mentioned in the post about customizing git logs, you can view the divergent history of your repository using the --graph flag.

From Git version 2.23, Git has introduced the switch subcommand which can be used to switch between branches.

To switch to a branch, run: git switch <branchName>.

To create and switch to a new branch: git switch --create <branchName>.

To return to the previously checked-out branch: git switch -.

Conclusion

A branch in Git is a simple file that contains the 40-character SHA-1 checksum of the commit it points to, making them extremely cheap and easy to create and destroy. Since we are recording the parent of commit, as mentioned in the previous post, Git can easily find the common merge base of two branches, making branches easy to use and merge.

Wondering how the git branch file is 41 bytes in size? 40 bytes for the 40-character checksum and 1 byte for the newline.

References

https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

Internal mechanics of Git commits - Secret to Git's speed and lightweightness

Ayush Poddar — Thu, 17 Aug 2023 13:33:47 +0000

After a series of posts that focused on the practical usage of some of the Git concepts, this post, once again, focuses on the internals of Git. I will tell you about the way Git works behind the scenes when we make a commit. This knowledge will help you understand why branching in Git is fast and extremely lightweight as compared to other version control systems, when we cover branching in a later post.

How does Git store the commit internally?

If you have read my post covering the internals of Git storage, you'd know that Git stores the full snapshots of your files when they change and are committed. When you make a commit, a commit object is created by Git which contains a pointer to the previous commit(s) (null in case of the first commit), a pointer to the snapshot of the content that has been committed, and metadata like the author's name, email and the commit message.

How is the snapshot created?

Assume that your repository's directory structure looks like this:

dir-1/
|-- 1-bar.txt
|-- 1-foo.txt
`-- dir-2/
    `-- 2-foo.txt

1 directory, 3 files

Assuming that all the files are modified and staged, Git first computes the checksum (SHA1 hash) of each file and stores those checksums as blobs.

file	blob checksum
`dir-1/1-bar.txt`	`da39a3`
`dir-1/1-foo.txt`	`1eaf2e`
`dir-1/dir-2/2-foo.txt`	`5f2a25`

You can run shasum <filename> to calculate the SHA1 checksum of a file.

Next, Git calculates the checksum of each subdirectory (essentially the checksum of all blobs in the subdirectory) and stores them as trees.

So, the "tree" for dir-1/dir-2 contains the blob checksum of dir-1/dir-2/2-foo.txt.

The "tree" for dir-1 contains the blob checksums of 1-bar.txt and 1-foo.txt, in addition to the tree checksum of dir-2.

To get the SHA1 checksum of a directory, you can run
shasum <file1> <file2> .. <fileN> | shasum
where file is a file inside the directory and its subdirectories.

Storage of commit

As already mentioned above, the commit object contains a pointer to the snapshot. In this case, our tree checksum for dir-1 would be the snapshot and its pointer is saved in the commit object.

If it is the first commit of the repository, the pointer to the previous commit is null. The next commit will point to the first commit, the third commit will point to the second commit and so on. In Git language, the previous commit is called a commit's parent.

Conclusion

In this post, you got a glimpse of how Git commits work internally and probably have an inkling of the reason behind Git's lightweightness and speed.

References

https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

Git Tags Continued - Share, Delete and Checkout

Ayush Poddar — Wed, 16 Aug 2023 08:22:00 +0000

In the previous post introducing Git tags, we learnt what Git tags are, how they are created and how we can view the existing tags. By default, when we run git push, Git does not push the tags you have created to the remote server (eg: Github). We need to be explicit in our intention when we want to push the tags to the remote server.

This post will be a continuation of the previous post, discussing on the following points:

How to push tags to a remote server
How to delete tags (locally and in the remote server)
Create branches based off a tag

How to push tags to a remote server

As already mentioned, merely running git push won't push the tags. In order to push tags to the remote server, we need to use the --tags flag. Hence the command would be:

git push --tags

# In case you want to push to a different origin
git push <remote> --tags

Using the --tags flag will push both annotated and lightweight tags. If you want to push the annotated tags only, then you can use the --follow-tags flag instead.

There is no way to push just the lightweight tags.

How to delete a tag

The command to delete a tag in your local Git repository is:

git tag -d <tagname>

Deleting the tag in the remote server

If the tag has been pushed to the remote server before deleting it in the local Git repository, you need to run another explicit command to delete the tag from the remote server too. The command is:

git push <remote> --delete <tagname>

# Example
git push origin --delete v1.0.1

There is another way to delete a tag in the remote server. The command is:
git push <remote> :refs/tags/<tagname>
The explanation of this command is: Push the part before the colon (:) to the remote tag named <tagname>. In this case, the part before the colon (:) is null.

How to create a branch based off a tag

The general command to create a branch is:

git checkout -b <newBranch> <reference>

where reference can be any valid Git object. Using this command, a new branch based off a tag can be created using:

git checkout -b <newBranch> <tagname>

If you are looking to just explore the code that is versioned by the tag, you can also directly checkout the tag using: git checkout <tagname>. Using this command puts your repository in detached HEAD state. You can use the link provided to learn more about it. I will also be exploring it in a future post of mine.

TL;DR of detached HEAD: In "detached HEAD", if you make some changes and commit them, the changes will not belong to any branch and will be lost. The only way to reach the commit would be by using its commit hash.

Final words

My hope is that by now, you are well equipped with dealing with the basics of Git tags, and are ready to tackle any new concepts that are thrown your way. Again, I also recommend reading my first post on Git tags.

References

https://git-scm.com/book/en/v2/Git-Basics-Tagging

Introduce checkpoints in your code - Learn how to use tagging in Git

Ayush Poddar — Tue, 15 Aug 2023 08:49:00 +0000

Tags in Git can be likened to checkpoints of a game. You can tag points in a repository's history that are important to you. Typically, tags are used to mark release versions like v1.0.0, v2.0.0, etc.

Tags are associated with a specific commit in your repository. In other words, after you create a commit, you can tag that commit with any name of you liking - e.g., v1.0.0, v2.0.0, etc.

In this post, I am going to tell you about the two types of tags in Git and how to create them.

Types of tags

There are two types of tags in Git:

Lightweight
Annotated

Lightweight tags

These tags are simply pointers to a commit. You can think of them as "bookmarks" to a commit. They cannot store any metadata apart from the name of the tag itself. As a best practice, these tags are generally used for temporary bookmarking and private use.

The command to create a lightweight tag is:

git tag <tagname>

where tagname can be anything that you want.

Annotated tags

Annotated tags are stored as independent objects in the Git database, with its own SHA1 hash, and metadata. They are capable of storing metadata such as author of the tag, email of the tagger, date of tagging and a message describing the tag. The command to create an annotated tag is:

git tag -a <tagname> -m <message>

# Example
git tag -a v1.0.0 -m "App is open to the public now"

If you provide a message using the -m flag, then you don't even need to provide the -a flag. You can just do: git tag <tagname> -m <message>

Annotated tags are useful when you want to push the tag to the public domain. They are useful because they can hold metadata like tagger's name and date of tagging. This information can help, for example, when trying to track the root cause of a bug.

Can a tag only point to the latest commit?

No. You can also create a tag that points to a previous commit. Consider the following git log:

305e248 - Ayush Poddar, 10 weeks ago : refactor: split into two methods
6f7f4ab - Ayush Poddar, 10 weeks ago : modify the instance doubles ensuring green specs
fe59bb7 - Ayush Poddar, 10 weeks ago : add logic to show different color for hidden files/directories
4f1333f - Ayush Poddar, 10 weeks ago : add colors for hidden files/directories
1e1f10c - Ayush Poddar, 10 weeks ago : modify indentations
28c188b - Claudio Bley, 3 months ago : Merge pull request #594 from ayushpoddar/show-abs-path-xargs
44c370b - Ayush Poddar, 3 months ago : Revert "version bump"

What if we want to create a tag that points to commit 1e1f10c (modify indentations)? You can simply add the commit hash (1e1f10c) at the end of the git tag command. So the command would look like this:

# Lightweight tag
git tag <tagname> 1e1f10c

# Annotated tag
git tag -a <tagname> -m <tag message> 1e1f10c

Viewing details of a tag

To view details of a tag, you can use the git show command. The command is:

git show <tagname>

The output differs slightly for lightweight and annotated tags. In case of lightweight tags, only the associated commit's information is displayed. The sample output is shown below.

commit 305e2486f4431fc7e0487423f90ed380852194b2
Author: Ayush Poddar <ayush.mail.id@gmail.com>
Date:   Wed Jun 7 18:00:34 2023 +0530

    refactor: split into two methods

diff --git a/lib/colorls/core.rb b/lib/colorls/core.rb
index b558968..f5f7707 100644
--- a/lib/colorls/core.rb
+++ b/lib/colorls/core.rb
@@ -416,20 +416,32 @@ module ColorLS

     def options(content)
       if content.directory?
-        key = content.name.downcase.to_sym
-        key = @folder_aliases[key] unless @folders.key? key
-        key = :folder if key.nil?
-        color = content.hidden? ? @colors[:hidden_dir] : @colors[:dir]
-        group = :folders
+        options_directory(content).values_at(:key, :color, :group)
       else
-        key = File.extname(content.name).delete_prefix('.').downcase.to_sym
-        key = @file_aliases[key] unless @files.key? key
-        color = file_color(content, key)
-        group = @files.key?(key) ? :recognized_files : :unrecognized_files
-        key = :file if key.nil?
+        options_file(content).values_at(:key, :color, :group)
       end
+    end
+
+    def options_directory(content)
+      key = content.name.downcase.to_sym
+      key = @folder_aliases[key] unless @folders.key?(key)
+      key = :folder if key.nil?
+
+      color = content.hidden? ? @colors[:hidden_dir] : @colors[:dir]
+
+      {key: key, color: color, group: :folders}
+    end
+
+    def options_file(content)
+      key = File.extname(content.name).delete_prefix('.').downcase.to_sym
+      key = @file_aliases[key] unless @files.key?(key)
+
+      color = file_color(content, key)
+      group = @files.key?(key) ? :recognized_files : :unrecognized_files
+
+      key = :file if key.nil?

-      [key, color, group]
+      {key: key, color: color, group: group}
     end

     def tree_contents(path)

In case of annotated tags, additional metadata such as tagger name, tagging date, etc. are also displayed. A sample output is given below. Notice the metadata displayed above the commit information.

tag annotated-tag
Tagger: Ayush Poddar <ayush.mail.id@gmail.com>
Date:   Tue Aug 15 13:38:36 2023 +0530

This is the sample tag

commit 305e2486f4431fc7e0487423f90ed380852194b2
Author: Ayush Poddar <ayush.mail.id@gmail.com>
Date:   Wed Jun 7 18:00:34 2023 +0530

    refactor: split into two methods

diff --git a/lib/colorls/core.rb b/lib/colorls/core.rb
index b558968..f5f7707 100644
--- a/lib/colorls/core.rb
+++ b/lib/colorls/core.rb
@@ -416,20 +416,32 @@ module ColorLS

     def options(content)
       if content.directory?
-        key = content.name.downcase.to_sym
-        key = @folder_aliases[key] unless @folders.key? key
-        key = :folder if key.nil?
-        color = content.hidden? ? @colors[:hidden_dir] : @colors[:dir]
-        group = :folders
+        options_directory(content).values_at(:key, :color, :group)
       else
-        key = File.extname(content.name).delete_prefix('.').downcase.to_sym
-        key = @file_aliases[key] unless @files.key? key
-        color = file_color(content, key)
-        group = @files.key?(key) ? :recognized_files : :unrecognized_files
-        key = :file if key.nil?
+        options_file(content).values_at(:key, :color, :group)
       end
+    end
+
+    def options_directory(content)
+      key = content.name.downcase.to_sym
+      key = @folder_aliases[key] unless @folders.key?(key)
+      key = :folder if key.nil?
+
+      color = content.hidden? ? @colors[:hidden_dir] : @colors[:dir]
+
+      {key: key, color: color, group: :folders}
+    end
+
+    def options_file(content)
+      key = File.extname(content.name).delete_prefix('.').downcase.to_sym
+      key = @file_aliases[key] unless @files.key?(key)
+
+      color = file_color(content, key)
+      group = @files.key?(key) ? :recognized_files : :unrecognized_files
+
+      key = :file if key.nil?

-      [key, color, group]
+      {key: key, color: color, group: group}
     end

     def tree_contents(path)

Listing tags

To list all tags in a repository, you can use the git tag command (without any arguments). You can also supply the --list (-l) flag which takes an optional argument.

Using git tag --list, as it is, will also list all the tags just like git tag would. The sample output of running git tag --list or git tag is shown below.

v1.0.0
v1.0.1
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.0.7
v1.0.8
v1.0.9
v1.1.0
v1.1.1
v1.2.0
v1.3.0
v1.3.1
v1.3.2
v1.3.3
v1.4.0
v1.4.1
v1.4.2
v1.4.3
v1.4.4
v1.4.5
v1.4.6

How to filter the tags by their name?

You can provide an argument to the --list flag to filter the tags. The argument needs to be the pattern that you want to filter by. The pattern can be the exact string to match or a shell wildcard. For example, if we want to view only those tags which start with "v1.0", we can do:

$ git tag --list 'v1.0.*'

# Output
v1.0.0
v1.0.1
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.0.7
v1.0.8
v1.0.9

How to filter for multiple patterns?

The --list flag can also take multiple arguments. In such a case, all tags which match any of the provided patterns will be listed. For example, if we want to list all tags which start with "v1.0", along with the tags which start with "v1.4" we can do:

$ git tag --list 'v1.0.*' 'v1.4.*'

# Output
v1.0.0
v1.0.1
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.0.7
v1.0.8
v1.0.9
v1.4.0
v1.4.1
v1.4.2
v1.4.3
v1.4.4
v1.4.5
v1.4.6

Conclusion

In this post, you learned about Git tags and the different types of tags supported by it. You also learned:

how to create tags
view details of a specific tag
List all the tags and filter them by their name

References

Git Remotes for Beginners: Inspect, Rename and Remove

Ayush Poddar — Mon, 14 Aug 2023 07:17:40 +0000

In the previous post, I introduced you to the concept of Git remotes. I showed you that a Git repository can have more than one remote and how you can fetch data from a particular remote.

In this post, I am about to answer the following questions:

How do you view more details about a particular remote? The branches present in the remote, and how those branches map to your local branches.
How do you rename a remote?
How do you stop tracking (remove) a remote from your Git repository?

View (Inspect) a Git remote

The command to achieve this is: git remote show <shortname>. For example, the sample output of running git remote show origin is shown below.

* remote origin
  Fetch URL: git@github.com:ayushpoddar/colorls.git
  Push  URL: git@github.com:ayushpoddar/colorls.git
  HEAD branch: main
  Remote branches:
    color-hidden-files  tracked
    main                tracked
    show-abs-path-xargs tracked
    size-in-bytes       tracked
  Local branches configured for 'git pull':
    color-hidden-files  merges with remote color-hidden-files
    main                merges with remote main
    show-abs-path-xargs merges with remote show-abs-path-xargs
    size-in-bytes       merges with remote size-in-bytes
  Local refs configured for 'git push':
    color-hidden-files  pushes to color-hidden-files  (up to date)
    main                pushes to main                (up to date)
    show-abs-path-xargs pushes to show-abs-path-xargs (up to date)
    size-in-bytes       pushes to size-in-bytes       (up to date)

I want you make the following observations:

This command outputs the full URL of the remote that the shortname is mapped to.
The list of branches in remote have been "fetched" to your local repository.
It lists the mapping between your local branches and remote branches. This helps you with knowing the remote branch that will be used when running git pull or git push on a local branch.

If you are wondering if the branch names in remote and the corresponding branch names in local can be different, I would encourage you to read this Github article.

How to rename a remote shortname?

Simple command.

git remote rename <old-shortname> <new-shortname>

How to remove a remote?

If you want to stop tracking a remote, you need to remove all references to the remote from your local repository. The command to do so is:

git remote remove <shortname>

# rm is an alias for remove
git remote rm <shortname>

Final words

After reading the first post and this post, you are equipped enough to understand any advanced ideas or commands that you may encounter. You can explore more on your own using man git-remote or git help remote.

References

https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

Git Remotes for Beginners: An Introductory Guide

Ayush Poddar — Sun, 13 Aug 2023 12:37:07 +0000

If you have read my post on the history of Git, you would know that in order to have effective collaboration, we need to have a version database that is accessible to everyone on the team.

You must also be aware of Github which is a very popular service that helps developers maintain their Git repositories online and enable easy collaboration by acting as the central version database.

In this post, I am interested in introducing you to the concept of Git remotes. The repository that you have uploaded to Github is an example of a Git remote. It is basically a copy of your local Git repository that is accessible to anyone you choose to share your repository with.

There can be more than one remote

Your repository can have multiple remotes, i.e., multiple remote copies of the repository with different read/write permissions for different users. A common case for multiple remotes is in the world of open source projects.

Generally, contributors clone the primary project repository and maintain their own remote copy of the repository (ever heard of forking?), where they push any changes they make. After they are sure of the changes they have made, they request the project maintainers to pull those changes into the primary repository.

A Git remote is represented by the URL of the repository. You must have seen URLs which are of the form git://github.com/<username>/<repo-name>. Since remembering URLs is difficult, Git also allows you to assign shortnames that map to these URLs. By default, when you clone a Git repository, Git assigns the shortname origin to the URL from where you have cloned.

How to list all remotes?

The command git remote lists all the remotes associated with your repository. Without any options, it just lists the shortnames. If you want to view the associated URLs too, then you need to use the --verbose (-v) option. Below is the sample output of the git remote -v command.

origin  git@github.com:ayushpoddar/colorls.git (fetch)
origin  git@github.com:ayushpoddar/colorls.git (push)
upstream    https://github.com/athityakumar/colorls.git (fetch)
upstream    https://github.com/athityakumar/colorls.git (push)

How to add a remote repository?

Apart from the default origin remote, you can add a remote to your repository explicitly. The command for doing so is:

git remote add <shortname> <url>

The shortname can be anything that you choose. As an example, you can add a remote named upstream with the following command:

git remote add upstream https://github.com/athityakumar/colorls.git

In order to fetch all the information from this new remote, you could run git fetch <shortname>. For example, running git fetch upstream in context of the above examples will output:

remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Total 4 (delta 3), reused 4 (delta 3), pack-reused 0
Unpacking objects: 100% (4/4), 555 bytes | 61.00 KiB/s, done.
From https://github.com/athityakumar/colorls
 * [new branch]      disable-mfa -> upstream/disable-mfa
   d1e28ed..28c188b  main        -> upstream/main

You can now access upstream's main branch at upstream/main.

If you try to run git checkout upstream/main, Git will display an elaborate warning. I will get into the details of this warning in a later post.

Does "git fetch" make any modifications?

No, it just downloads the repository data to your local repository. It does not merge any changes or modify any of your files.

References

https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

Un-stage and un-modify a file in Git - Part 2

Ayush Poddar — Sat, 12 Aug 2023 03:37:09 +0000

This post is part of my “Shorts” series, where each post is concise and hyper-focused on a single concept.

In a previous post, we learned about the git rm command which helps you un-stage a file, and delete any modifications made. However, the git rm command is essentially meant to “delete” files, not undo them.

Git offers a dedicated command to undo modifications, or undo staging of a file. In this post, I will introduce you to git restore which can be used to perform both these tasks.

Git introduced git restore in version 2.23.0. Earlier, the commands git reset and git checkout were used for the same purposes. But, git restore was introduced as a more dedicated tool for these specific purposes.

I will not cover the details of the git restore command since Git is very helpful with these commands, and I think it is best for you to explore them yourself. When you run git status, Git exactly tells you the commands to un-stage or undo any unstaged modifications. This is how the output of git status looks like. Notice the commands mentioned for undo-ing.

On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   ammend.md

Fair warning

If you use git restore <file> to undo any unstaged modifications to a file, then you will lose all those changes forever. Git only helps you recover changes that have ever been committed.

If you are feeling uneasy about losing those modifications forever, but still want to undo the modifications, a better way is to use git stash. I will explore this command in a later post.

Further exploration

As always, I encourage you to explore the command further using man git-restore.