MMM February 2016

Are git tags faster to access than git commits?

I am uncertain if the title of the question is most appropriate.

I have data in text files. This data changes/grows every day. I keep the directory holding this data under source control, git. At the end of every day, I issue a command:

git commit -m "EOD YYYYMMDD"

Often, I need to see what the data looked like at some day in the past.

  1. Is it different to use tags as opposed to commits?
  2. Are tags faster to access than commits, meaning, is it faster to checkout a given file as it was at the EOD of some day in past with the help of tags as opposed to commits?
  3. Is 1 more space efficient than another? (the size of my directory is 3Gigs of text)

Answers


David Deutsch February 2016

A git tag points to a commit; the former does not really make sense without the latter. And if you want to be able to see what the data looked like at some day in the past, you must commit it; that is what a commit is for. So long story short, you are doing it correctly.


MikeMB February 2016

In case this is not clear: Using tags doesn't mean you no longer have to make commits. An (annotated) tag is little more than a commit with some additional meta information and a lightweight tag is literally just a pointer to a commit (like a branch).

So the answer to questions 3 is definitively no.

For question 2: The checkout doesn't happen any faster, but if you e.g. don't know the exact content of the commit message it might be easier for you to list the available tags and find the commit you are looking for - simply because there are fewer of them.

Finally to your question number 1: Again, tags are just annotations for commits that are designed to make it easier to find a certain version of your files that has special meaning for you.


trentcl February 2016

Tags point to commits. You can't create a tag unless there is a commit for it to point to. So there is not really a choice here.

(As for space, a tag will always consume more space than no tag, but tags are just short text files, so creating a thousand of them will only net a couple megabytes at most.)

You certainly can create tags named (for example) eod-20160208 after making your end-of-day commit, and then check out the code as it was today by running a simple git checkout eod-20160208. This will be easier than looking through your recent commits for the one with the relevant commit message, but not particularly easier than skipping the tag altogether and running git checkout 'master@{2016-02-08}'.

This brings me to another point: Git keeps track of the date for you. I won't say you are using it wrong, because Git supports a variety of different workflows; but putting the date in the commit message is a bit redundant. If you're using git log, gitk or something to view your commit history, the date is listed right there next to the commit message. So I recommend using -m to describe the changes you made, not to specify when you did it. This strategy helps me find the change I'm looking for faster.


Philippe February 2016

1.Is it different to use tags as opposed to commits?

No. Tags is just a little sticker more humanly understandable to point toward a commit.

  1. Are tags faster to access than commits, meaning, is it faster to checkout a given file as it was at the EOD of some day in past with the help of tags as opposed to commits?

No, because in the end, you check out the commit pointed by the tag. The only thing that play a role in check out time is how far the target working directory is far from the current working directory (what are the changes that should be apply from one to obtain the other!)

  1. Is 1 more space efficient than another? (the size of my directory is 3Gigs of text)

Tags take nearly to place but that's not where data are stored (which is the commits). Tags are just a convenient way to memorise some important commits to find them more easily in the future.

Post Status

Asked in February 2016
Viewed 1,689 times
Voted 14
Answered 4 times

Search




Leave an answer