In Git, every line of the file .gitignore is a regular expression that describes files that should be ignored. However, one can also add lines that state which files not to ignore.

Example:

The following example shows a configuration that ignores everything in a particular directory (./tmp) but explicitly states that PDF files in ./tmp should not be ignored:

 

The suggested way of adding all untracked files to the index in Git is to use the interactive add command:

This can be fully automated as follows:

The commands entered via standard input (a,*,q) will not be printed. For convenience, we can also define an alias in ~/.gitconfig:

References

  • [1] Mat’s and EAGER_STUDENT’s answer on StackOverflow

 

git-svn keeps empty directories, which may become a problem (e.g.) when renaming directories. This behavior manifests in messages such as “W: -empty_dir abc/dir” during dcommit and, how it can be altered, I describe in this article.

Configuration for removing empty directories during git svn dcommit

To avoid keeping empty directories around, use the –rmdir flag during git svn dcommit:

To make this behavior permanent, we can use git config (Can be verified by taking a look at the [svn] section in ~/.gitconfig):

Now, when performing svn dcommit, you should see that empty directories get deleted (see the lines starting with D+).

Removing legacy empty directories

For the time being, we only fixed the future behavior of git svn, but there are still empty directories left in the Subversion repository. To clean these up, we need an Subversion working copy of the repository. Go to the SVN working copy and determine the empty directories:

This call will exclude the .svn directory (-prune flag) and include the “lowest” empty directories in the directory tree. Therefore, we need to iterate the deletion procedure several times until no more empty “leaf directories” remain. Next, investigate empty_dirs.txt and see whether it contains directories that you want to keep – edit empty_dirs.txt if necessary:

Now comes the time to schedule the directories for deletion (if there remain empty directories to be deleted):

Now, rerun the find command to find directories that are now eligible for deletion and repeat the xargs svn delete. At the end, review you changes with svn status and commit them with

Finally, the same steps have to be performed in the git svn working copy after a git svn rebase.

References

  • [1] Peter Boling describes a similar solution

When you create a new ‘mirror’ of a Git repository, you would like to copy all branches and all tags to that location. There is only single command that performs this task:

If you only want to push the tags, use

 

A local Git repository holds a copy of any remote branch that has ever been fetched. Even though remote branches (origin/…) may already have been deleted, the local copies of these branches are kept indefinitely if we do not delete them by hand.

The following command removes missing remote branches of remote origin:

For testing purposes we may add the option –dry-run.

References

  • [1] git remote man page

The following is a suggested setup of the Git configuration file (_~/.gitconfig):

From time to time you want to take a look at a file in the past of your Git repository’s history. The following instructions will tell you how to see (and save) a file at a certain commit in the Git history.

Finding the right commit

Depending on the use case there are different ways of finding the commit you want to take a look at. In any case, after this step you will have a commit id or a branch-relative index which can be used to refer to the desired commit.

Referring to recent commit

If you know that the file was in the desired state in the previous, last but one, etc. commit, you can use the “~ operator”:

  • previous commit: HEAD~1
  • last but one commit: HEAD~2
  • head of certain branch: branch123
  • commit before head of branch: branch123~1
  • etc.

Listing files under version control

The command git ls-tree shows you the files which were under version control at a certain point in time:

Deleted files

Suppose you have deleted the file and want to know in which particular commit you deleted it, then the following command will be helpful, which prints out all log entries which contain a delete instruction (you may search as normal with the “/” operator):

Git bisection search

If you don’t know the exact version (commit) of the file, but given the file in some state, you can decide whether the appropriate version has been created rather before or after a given one. In this case the bisection search of Git may help: You tell Git a range of commits which surely “enclose” the desired version of your file. The most recent commit is called the bad state and the oldest commit is called the good state, because the bisection search is meant for finding a commit which introduced a bug which has not been there at some point in the past. In our setting, we are not looking for a bug but for a particular version of a file.

The bisection search will place you at the “center” between good and bad (you can also visualize the situation with the command git bisect visualize). And now you can examine the file in question whether you think the change is in the future or the past of this commit. In the former case (“future”), our we need to tell Git that the current state is good (“bug” in the future):

Likewise, in the latter case we find that the “bug” is in the past and tell Git so:

Iterate, until you are done. Then, or if you would like to abort the bisection, type:

Restoring the file

Now that you have the commit of your choice, use the git show command to display or store the file.

shows README.txt file in the 3rd last commit of the current branch.

shows index.html in the subdirectory doc/html in the state it was one commit before the HEAD of the branch issue123.

It may happen that you create a local branch and forget to make it track a remote branch. We can make up for this by using the –set-upstream-to option of the git branch command. Say we are currently on branch issue123 and we want to make this branch track origin‘s issue123 branch.

For Git versions >=1.8

For Git versions <= 1.7

Mind the switched order of arguments. This command will also work in later Git versions:

 Links