DEV Community: root

Fixing Mistakes in Git

root — Sun, 11 Oct 2020 11:54:22 +0000

Let's be real here, we all make mistakes when we code and to make matters worse we persist those changes in a version control system like Github. Sometimes they are benign and on the other hand it can cause a lot of damage.

In this blog I will discuss ways by which you can fix your mistakes when using git.

PS: Keeping your commits "Atomic" would go a long way in helping you fix your mistakes, since you can throw a commit the introduced the issue with confidence.

There are a lot of ways you can fix mistakes in commits and each way is suitable under a specific circumstance. From a practical stand point we can broadly classify mistakes into types types

Pushed commit to remote repository
Commits that are not pushed to remote repository

Pushed to remote

When commits are pushed to remote, To be on the safer side we should assume that other people might have already pulled the changes.

Git revert

you can easily remove a commit from the repository by doing a git revert.
Revert does not actually remove the commit, instead it will create a new commit which reverts the changes done in the commit.

Revert in action.

# find the commit hash of the commit you want to revert
$ git log --oneline 
d77ce47 (HEAD -> master) add instructions
e3a5bd7 bad commit
e6f780f first commit


# Revert the commit
$ git revert e3a5bd7
git revert e3a5bd7
[master 5c69f9f] Revert "bad commit"
 1 file changed, 2 deletions(-)

# list commits again
$ git log --oneline
5c69f9f (HEAD -> master) Revert "bad commit"
d77ce47 add instructions
e3a5bd7 bad commit
e6f780f first commit

Not pushed to remote

We have a lot of options when it comes to fixing mistakes that are not pushed.
Depending on the situation we can choose different approaches

Mistake in the last commit

If the mistake is in the last commit we can use

commit amend
git reset

Commit amend

With commit amend you can make changes and add the changes on top of the last commit.

Scenario:
I created a new feature but I missed to add an file which should be part of that commit.

$ git log --oneline
6a1d188 (HEAD -> master) added new feature
90c9958 first commit

# we missed the feature.txt which should be in the last commit.
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    feature.txt

nothing added to commit but untracked files present (use "git add" to track)

# Add the file and use amend to modify commit
$ git add feature.txt
$ git commit --amend
[master d2bd903] added new feature
 Date: Sun Oct 11 15:19:09 2020 +0530
 2 files changed, 2 insertions(+)
 create mode 100644 feature.txt

# check log
$ git log --oneline
d2bd903 (HEAD -> master) added new feature
90c9958 first commit

Git reset

Git reset is very versatile. simply put we can use reset to undo commits.

to undo last commit

$ git reset HEAD^1
Unstaged changes after reset:
M   README.md

Fixing intermediate commit

Git reset

if do not wish to keep changes after the commit you want to change you can undo all the commits from the bad commit.

$ git log --oneline
36c4f05 (HEAD -> master) fix bug
e344740 added new feature
90c9958 first commit

# for fixing mistake in `e344740 added new feature` 
$ git reset e344740~1
Unstaged changes after reset:
M   README.md

$ git log --oneline 
90c9958 (HEAD -> master) first commit

The disadvantage of using this is that the commits after the commit that you want to change are also lost. This can be troublesome for you if you need the other commits, in that case you can use git rebase.

Git rebase

To fix commit without removing / modifying other commits we can use rebase.

Scenario:
delete the commit fix bug.

$ git log --oneline
cf037c9 (HEAD -> master) add test file
36c4f05 fix bug
e344740 added new feature
90c9958 first commit

$ git rebase -i 36c4f05~1

-i is for interactive mode, this command will open a text editor allowing you to enter what you want to do with each commit.

to delete a commit we should specify drop for the corresponding commit.

once you exit from editor the rebase will be applied and check git logs to see the commits

$ git log --oneline
608fc51 (HEAD -> master) add test file
e344740 added new feature
90c9958 first commit

if you want to modify the commit you can specify edit instead of drop.
it will pause the rebasing at that commit and you can make changes then continue the rebasing with git rebase --continue

Hope this was informative, stay tuned for more git related blogs :)

Git does not store Diffs

root — Sun, 04 Oct 2020 19:10:43 +0000

This is a common misconception around git. For a git beginner it makes logical sense to assume so, as Git exposes commit as diffs to the end user as that makes it easier to identify changes as shown in the image below.

But Git does not internally store diffs for each commit, it creates a snapshot of the files during each commit.
This means that if you create a file in one commit and modify the same file in second commit, Git will have 2 snapshots for the same file.

To show you how git internally stores these files, we are going to dig into the .git/ folder. Understanding how git handles files will give a better picture, check out my blog on Git Objects for the same.
TLDR : All the files we add to git repository are added as objects in the .git/objects/ repository.

(Please skip over to the Why ? section at the end for the reasoning behind using snapshots vs diffs)

Let's see this in action

$ mkdir gitinternals && cd gitinternals # create and cd into a dir
$ git init # initialize git
Initialized empty Git repository in /Users/home/gitinternals/.git/

Now that we have a fresh git repository lets create a file and commit it.

$ echo "# Hello world" > README.md
$ git add README.md
$ git commit -m "Add readme file"
[master (root-commit) 0948529] Add readme file
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Let's take a look at the git object directory, it will have the readme file stored.

$  tree -a .git/objects/
.git/objects/
├── 09
│   └── 4852928af802dfe0f463359c7ade3f7a21fffa
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── a5
│   └── ef91ee14be786131cbecfd2eb8c7fef8a2510d
├── info
└── pack

The objects directory has three objects, we can check the type of object file with the cat-file -t plumbing command.
with that we can see the 716e is the Blob file, which should be our README.md file, as we only have one blob file in our repository. using cat-file -p we can see the contents of the object file.
Please feel free to refer back to Git Objects, if you want to know more on Git objects.

$  git cat-file -t 716e
blob

$ git cat-file -p 716e
# Hello world

Let's modify the readme to add a . at the end of the file and create a commit again

$ echo "." >> README.md
$ git add README.md
$ git commit -m "Update readme"
[master ccab425] Update readme
 1 file changed, 1 insertion(+)

Checking the objects directory

$ tree -a .git/objects/
.git/objects/
├── 09
│   └── 4852928af802dfe0f463359c7ade3f7a21fffa
├── 28
│   └── af00ee0e3e44d7806dc1c2d7f1a9c9d75cfd8e
├── 5f
│   └── a99c8ea90f41ae4601f92ea7475832e6fb773d
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── a5
│   └── ef91ee14be786131cbecfd2eb8c7fef8a2510d
├── cc
│   └── ab425bf34937b0e02ed807724af39812e8988b
├── info
└── pack

there are a few more objects in the directory. to get the blob file we can check each file for the type and figure out which one is the new version of README.md but there is a better methodological approach to it.

we can take the current commit hash and check what tree that has points to and from the tree hash we should be able to get the blob hash, Please refer to Git Objects in case if you are unfamiliar with commits and trees objects.

# get hash of current commit
$ git rev-parse --short HEAD
ccab425

# check content of the commit to get tree hash
$ git cat-file -p ccab425
tree 28af00ee0e3e44d7806dc1c2d7f1a9c9d75cfd8e
parent 094852928af802dfe0f463359c7ade3f7a21fffa
author root <root@email.com> 1601836557 +0530
committer root <root@email.com> 1601836557 +0530

Update readme

# check content of tree `28af00`
$ git cat-file -p 28af00
100644 blob 5fa99c8ea90f41ae4601f92ea7475832e6fb773d    README.md

the hash of new README.md snapshot is 5fa99c, lets inspect the old and new snapshot content.

# New snapshot hash
$ git cat-file -p 5fa99c
# Hello world
.

# Old snapshot hash
git cat-file -p 716ed1
# Hello world

Why ?

This might seem un efficient to store each version of file as snapshot as storing just the diffs would be most efficient use of storage. so it is only natural to ask why ?

Storing diffs and applying diffs on top of base file version can become pretty computationally expensive when you are on large projects with thousands or even millions of files.
The diff based approach is used by SVN and there are common issues with large projects taking hours just to checkout as CPU and IO becomes bottleneck to apply those diffs.

And SVN was popular when storage was costlier than compute but the tables have changed now. storage is much more cheaper in this day and age, which makes Git the perfect choice for version control.

Git has some optimization built in for compressing objects so that they take lesser storage on disk, which we will cover in an upcoming blog :).

Git Objects

root — Sat, 03 Oct 2020 20:33:08 +0000

I always loved git, In this series of blogs I am documenting about git internals that I learned along the way.

In this blog I am writing about Git Objects, Simply put Object is the storage Unit of Git. All the files, commits, trees and tags in a git repository is stored as Objects. If you are new to Git this will seem a bit cloudy, don't worry, the weather will clear up as you go along with the blog.

Let's start off by creating a new git repo for us to experiment.

$ mkdir gitinternals && cd gitinternals # create and cd into a dir
$ git init # initialize git
Initialized empty Git repository in /Users/home/gitinternals/.git/

with the above commands you will have initialized a git repository locally. This will have created a .git folder inside your repository. this is where git stores all its internal data related to this repository.
A quick tree -a on the current folder will display the files and folders created by git.

$ tree -a
.
└── .git
    ├── HEAD
    ├── config
    ├── description
    ├── hooks
    │   ├── applypatch-msg.sample
    │   ├── commit-msg.sample
    │   ├── fsmonitor-watchman.sample
    │   ├── post-update.sample
    │   ├── pre-applypatch.sample
    │   ├── pre-commit.sample
    │   ├── pre-merge-commit.sample
    │   ├── pre-push.sample
    │   ├── pre-rebase.sample
    │   ├── pre-receive.sample
    │   ├── prepare-commit-msg.sample
    │   └── update.sample
    ├── info
    │   └── exclude
    ├── objects
    │   ├── info
    │   └── pack
    └── refs
        ├── heads
        └── tags

we are interested in the .git/objects directory, this is also referred to as the Object database of git. initially it just has the info and pack folders, no objects just yet.

Blob objects

Git considers all the physical files that user work with in the git repo be it text files, images, audio, video as BLOB(Binary Large OBject).
Let's create new file in the folder and check how git reacts to it.

$ echo "# Hello world" > README.md
$ tree -a .git/objects/
.git/objects/
├── info
└── pack

Running tree on the objects directory reveals that there is no changes in the object storage, This is because git has not started tracking the file yet. you can confirm this by giving the command git status

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

README.md file is listed under the untracked files yet. that means that git does not care what you do with the file. The git status gives us info on how to make git track the file.

$ git add README.md
$  tree -a .git/objects/
.git/objects/
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── info
└── pack

at last we see some activity in the objects folder.
The string 716ed1421c738a75abe6e0c4812ad4aacee0e11a is the SHA-1 hash of the README.md file.
the first 2 letters of the hash is used as a folder and remaining string is used as the file name.

we can verify the hash of the file with the hash-object plumbing command

$ git hash-object README.md
716ed1421c738a75abe6e0c4812ad4aacee0e11a

we can also check the contents, type and size of a object with the cat-file plumbing command

$ git cat-file -p 716ed1421c738a75abe6e0c4812ad4aacee0e11a
# Hello world

$ get cat-file -p 716e # we need not type the whole hash, a hash prefix which uniquely identifies the hash can also be used.
# Hello world

$ git cat-file -t 716e # checking type of object
blob

$  git cat-file -s 716e # checking size of object
14

Here we see the type of object is blob, which is expected for the file README.md

Commit Objects

Let's create a new commit in our repository and we will look at how the objects directory has reacted to our commit.

$ git commit -m "Add readme file"
[master (root-commit) 0948529] Add readme file
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

$  tree -a .git/objects/
.git/objects/
├── 09
│   └── 4852928af802dfe0f463359c7ade3f7a21fffa
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── a5
│   └── ef91ee14be786131cbecfd2eb8c7fef8a2510d
├── info
└── pack

We see two more objects 0948 and a5ef, let's check these type of objects with the cat-file command.

$ git cat-file -t 0948
commit

$ git cat-file -t a5ef
tree

we that 0948 is a commit object and a5ef is a tree object.
let's check the contents of the commit object

$ git cat-file -p 0948
tree a5ef91ee14be786131cbecfd2eb8c7fef8a2510d
author root <root@email.com> 1601801983 +0530
committer root <root@email.com> 1601801983 +0530

Add readme file

tree a5ef91ee14be786131cbecfd2eb8c7fef8a2510d

This is the tree that this commit is pointing to, more on Tree next :)

author root root@email.com 1601801983 +0530
committer root root@email.com 1601801983 +0530

The next two lines contain the author and committer info.

Add readme file

And then separated by a new line we have the commit message.

Tree Object

Tree objects stores a group of blob objects and tree objects. conceptually it makes it easier for us to think of tree object as snapshot of the folder.
Each folder can have multiple files and multiple folders within them, Likewise Tree object can have multiple blob objects or multiple trees in them.

Lets inspect the content of the tree object a5ef

$ git cat-file -p a5ef
100644 blob 716ed1421c738a75abe6e0c4812ad4aacee0e11a    README.md

This tree object has only one file in it as we have added only one file to the git repository.

the tree object content has four parts

part	description
100644	100 means that it is a normal blob object and 644 is the file permission on the disk
blob	type of object
716ed1421c738a75abe6e0c4812ad4aacee0e11a	object name
README.md	file name

Tag Object

Adding a new tag to our current commit, let's observe how our object directory reacts.

$ git tag -a v0.0.1 -m "my version 0.0.1"

$  tree -a .git/objects/
.git/objects/
├── 08
│   └── a57a8e9c4b340f5674b96652595bf6727b35bd
├── 09
│   └── 4852928af802dfe0f463359c7ade3f7a21fffa
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── a5
│   └── ef91ee14be786131cbecfd2eb8c7fef8a2510d
├── info
└── pack


$ git cat-file -p 08a5
object 094852928af802dfe0f463359c7ade3f7a21fffa
type commit
tag v0.0.1
tagger root <root@email.com> 1601811513 +0530

my version 0.0.1

Upon checking the contents of the Tag object file 08a5

we see that the tag object points to the current commit 0948. and it has the tag information along with the author who created the tag.

Hope this gave you some insight on internal working of git. Follow me for more git internal related blogs :)