Moving from SVN to git: $Id:$ equivalent

In SVN (and CVS), you could include special strings such as

1

$Id:$

and after a commit, the revision number would appear after “Id:”, which was a convenient way to retrieve the revision for instance in a print statement.

Apparently, with GIT, the equivalent does not exist by default. Indeed somebody could refer to version 1.1 of a file but your
version 1.1 of that file is different and so it would not make sense to keep track of a revision.

Yet, there is way to include the hash from GIT. First, go the repository you are working one and add (if you want to add $Id:$ in a Python code):

1 2 3

cat .git/info/attributes # see man gitattributes *.py ident

Then put $Id$ somewhere in the file (on top generally)

Then commit. Note you will need to delete the file and check it out again:

1 2 3

git commit foo.sh rm foo.sh git co foo.sh

You should now see the $Id: followed by a commit hash string:

1	# $Id: 143e77a7f07343b14 $

reference: http://stackoverflow.com/questions/384108/moving-from-cvs-to-git-id-equivalent

I have no experience with SVN , butI believe the git way of doing this would be with tags.

After a specific commit, you can do:
git tag -a -m “”
Afterwards, you can simply do:
git checkout
That will check you out to the specific commit where the tag was created.

To push tags:
git push –tags

To pull, simply:
git fetch

git error: cannot do a partial commit during a merge.

After a pull command, I ended up with a conflict in a file, which I fixed by manually editing the file (search for the <<< signs). The merge is fine and therefore tried to commit the file again but got this error:

1	fatal: cannot do a partial commit during a merge.

Using :

1	git commit -a my_filename

did not work, instead use

1	git commit -i my_filename

From the git documentation, the -i should be used to conclude a conflicted merge.

GIT: How to Create Git Aliases

An alias, otherwise known as a shortcut, allows to place a simple command in front of a longer or less memorable command.

For example, we could type:

git commit -m "some change"

Or we could type even less and do:

git c -m "some change"

We’re only saving a few letters but considering how many times you commit in a day or week, it’s a bit easier on your fingers. Less tapping of the keyboard and more working on the fun code.

To create a Git alias, we need to open up our .gitconfig file and edit it. Because we want to have these aliases available to us in every project, we are going to edit the .gitconfig file in our user directory.

If you don’t already have the file in your user directory, that’s okay. We can have Git handle that for us.

We’ll create an alias first using the git-config command, to which we pass the type of config file (in our case it’ll be global in our user home directory) and then define the alias.

git config --global alias.c commit

This will add the following line to our ~/.gitconfig file. Let’s take a look to see if it was saved.

git config --list

This lists out all of our config items and you should see the alias:

c = commit

listed as output.

Now we have access to that alias within Git. We can type:

git c -m "something"

and it will work just as if we typed out the full command.

Let’s open up the config file and take a look. We’ll open ours in Vim, but you can use any editor you want.

vim ~/.gitconfig

You should see something like this:

[alias]
    c = commit

Let’s add another alias by hand without using the git-config command. It’s just a text file so we can edit it and type out our alias by hand.

Let’s add an alias to make it quicker to get the status of our working directory. Under the existing alias for commit, let’s add this:

st = status

We’ll save our .gitignore file and then try it out.

git st

And we should get some output from Git (assuming we’re inside a Git project) as if we ran the full command.

We can add another for git-log, too.

l = log

And how retrieving the basic log is two letters faster than before!

Okay, let’s do one more to quickly archive the entire repository.

Git provides a command called git-archive that allows us to export the entire repository as either a zip for tar archive file.

git archive --format=zip -o latest.zip HEAD 

This command will output the current repository at HEAD to the a zip file named latest.zip. It will save the file right where you are in the repository.

This can come in handy if you have to quickly share your work with someone who is not in the Git repository or if you need to throw the files up on a server somewhere.

To alias this we add this to our .gitconfig file:

zip = git archive --format=zip -o latest.zip HEAD

Now when we run:

git zip

in a valid Git project directory, git-archive will zip up the entire project and place it in the project root.

One Bit of Advice

You don’t have to have a fully decked out .gitconfig file right from the get-go. Add aliases to your config file as it makes sense and as you need them. They can be tough to remember if you add too many at once!

GIT: The Slowest Git Commit in the World

In Git there’s the concept of “porcelain” commands and “plumbing” commands.

This obvious allusion to the toilet and its two types of interfaces. The simple, yet functional, porcelain. You interface with it and get the job done.

Behind the scenes is the plumbing. This does the dirty work of completing the job.

In Git, we have the same thing. The porcelain commands are the commands that you’ll typically use from the command line. git commit, etc.

The plumbing commands are the low level commands that make up the Git system. They are the commands that do the, uh, dirty work, and make your repository track and manage files and changes.

In this video, follow along as Ryan uses Git plumbing commands to manually hash, create and commit objects in Git.

We’ll start off by creating a new directory for our project and initializing a fresh repository.

And we’ll end up with the slowest Git commit in the world.

GIT: How can I delete a commit in Git?

Git offers a couple of tools to delete (or undo) older commits. The first step, therefore, is to find out which tool is best for your scenario.

Restoring an old version of a project

Do you want to restore an older revision of your project - just as it was at a certain point in time?

In that case, the "git reset" command is what best suits your needs. Read more in our detailed post about how to reset to a previous revision.

Undoing only a specific commit

A different scenario is when you want to revert the effects of a certain commit - without deleting any commits that came afterwards.

This is a case for the "git revert" command. Interestingly, the command doesn't deleteanything; it creates a new commit that introduces changes which revert the effects of the specified commit. Our post explains the details of how to go about reverting commits.

Delete or change specific commits

Another use case might be to delete a commit "in the middle" of your history, without resetting your whole project to a previous revision.

In that case, we'll have to bring out the big guns: Git's "Interactive Rebase" tool is what we need here. Please note that this is not only the most powerful, but also the most dangerous of the three commands listed here. This is because it allows you to change your commit history quite drastically - which is a dangerous process.

Read more about Interactive Rebase, including what to watch out for.