3

In mercurial, I am used to being able to do hg up 00 to completely clean out the working directory.

This resets the working directory to it's state immediately after having performed the hg init.

Is there any equivalent in git?

Note that hg up 00 is not the same as hg up 0, which updates to the first revision committed, instead it is equivalent to hg up null, just a couple of characters shorter to type. *8')

Also note that I don't want to just do an rm -rf * in the root of the git working directory, as then git status will show all of the files as having been removed. I just want to update the repository to it's state prior to the first commit. Alas my searches through the web and the git manuals haven't furnished me with the info I need to work out how to do it in git.

As background, I want to leave the repository in place so that I can easily checkout a different commit later. One reason I want to do this is that I have a very large repository (actually a git svn repo) and I don't want to have to ever have to re-clone it again (it took days to complete and you aren't supposed to clone a gitsvn repo). I do want to be able to free up the space taken by the working copy when I don't need it though.

Mark Booth
  • 6,794
  • 2
  • 60
  • 88
  • And you don't want to delete .git directory? – Nylon Smile Jan 14 '11 at 12:03
  • This seems as strange thing to do. If you want to reset to a blank repo, why not just create a blank repo. Maybe if you explained why you want to do this you might get some git-like suggestions. – Abizern Jan 14 '11 at 12:09
  • @Nylon - That would be resetting to the state before `git init`. The OP wants to roll-back to the state just after `git init` – Abizern Jan 14 '11 at 12:10

3 Answers3

2

This seems like an unusual thing to want to do, git branches start with an initial commit that is usually non-empty. You can't "checkout" or "reset" to before this initial commit with usual git commands.

You can reset the currently checkout branch to an "uncreated" state ready for a new initial commit with this command.

git updated-ref -d "$(git symbolic-ref HEAD)"

This deletes the currently checked out branch.

You can then remove all files from the index with this command (assuming that you are at the root of your repository).

git rm -r --cached .

You may need a -f switch if you have unstaged changes.

Finally you can clean all files from your working tree with this command. Warning: potentially dangerous.

git clean -fd # WARNING, dangerous
CB Bailey
  • 648,528
  • 94
  • 608
  • 638
  • Thanks Charles, but having tried that on a test repo, I find that `git status` still shows all of the files as having been deleted. I'm going to have to learn more about refs I think. Coming from an `hg` background, I'm still finding `git` a bit of a culture shock. – Mark Booth Jan 14 '11 at 12:21
  • @MarkBooth: Did you run all three commands? By the end all files should have been deleted from the index and the working tree. Isn't this what you wanted? – CB Bailey Jan 14 '11 at 12:25
  • Thanks again Charles, I must have mis-applied the commands the first time, as I've just tried again with a new test repo and that seems to have worked. The trouble now is that I have no idea how to get it back to a given revision. I've had a look at the `git update-ref` man page, but I don't understand enough about refs yet to digest it. – Mark Booth Jan 14 '11 at 14:41
  • @MarkBooth: What state are you trying to get back to? I though you wanted to rewind completely to before the initial commit? If you want to reset the branch back to a known commit you can just do `git reset ` . – CB Bailey Jan 14 '11 at 15:39
  • Ok, if I do `git init; touch a; git add .; git commit -ma; touch b; git add .; git commit -mb; git log` and then follow your instructions, I get a clean working directory. If I then do `git reset ; git status` then it tells me that a has been deleted. Oh, I see, you then need to do `git reset --hard` to bring the files back. Thanks - I think I understand now. – Mark Booth Jan 14 '11 at 17:09
2

The equivalent of the null revision is called bare repository in git. This search gives a rough overview of the topic, different ways of converting a non bare into a bare repo can be found here.

Unlike hg, there is no easy way to switch between a bare and a non-bare repository. Also you should not push into a non-bare repository, as a push will change the index of git, but does not update the working tree. See Working with git from 2 laptops with no bare repo for details.

Community
  • 1
  • 1
Rudi
  • 17,566
  • 3
  • 50
  • 74
  • Thanks Rudi, this has filled in a blank space in my knowledge that has allowed me to work out what should work for me. Essentially, I need to use `git clone --bare -l gitsvn.partial gitsvn.partial.bare/.git` to create the partial (I can then `rm -rf gitsvn.partial` to reclaim the space), then to get it back, I can use `git clone -l gitsvn.partial.bare gitsvn.partial`. The first is really quick, since it uses hard links, but getting it back will take a lot longer, since it needs to update the working directory. Even then it will be much quicker than re-cloning. – Mark Booth Jan 14 '11 at 14:53
1

These are solutions that come to my mind:

1- You can remove .git directory from your working directory and there will be no git repository in your working directory.

2- You can reset to initial commit(the initial commit will still remain) by issuing:

git reset --hard `git rev-list HEAD | tail -n 1`
Nylon Smile
  • 7,414
  • 1
  • 20
  • 31
  • That's generally useful, but for the huge git svn repo I'm thinking of at the moment it wouldn't help me much. The first commit is part way through the original svn repo, so already pretty large. – Mark Booth Jan 14 '11 at 12:24