28

I just refactored my project's entire codebase. So much so that even though it uses most of the same code base, things work in a radically different way. If the old version was 1.0, the new one would be 2.0. The project itself is just under 1mb in size (its a tiny little lib). I started the project a long time ago and its undergone many changes... so many that my git folder is now over 3mb in size.

In this case 3mb is a very small amount of data, but from a 'big picture' perspective, when should you cut your previous VCS history out of your current project and start over? Or should you never ever do this?

gnat
  • 21,442
  • 29
  • 112
  • 288
Pris
  • 385
  • 2
  • 5
  • @Pris: please replace "git" by "VCS", this question is in no way specific to git. – Doc Brown Jan 07 '13 at 13:42
  • @DocBrown: In svn you can edit history (remove/add revisions) while in git you basically have to create a new repository to delete revisions once pushed upstream. I basically know only svn and git, but the differentiation may still be present in on other VCSes. – Hubert Kario Jan 07 '13 at 13:51
  • 1
    @HubertKario: *in svn you can edit history*? That's new to me. I was under the impression that the SVN situation is not different here. – Doc Brown Jan 07 '13 at 14:03
  • 1
    @DocBrown You can, but it requires full import and export with `svnadmin` and filtering with `svndumpfilter`. Those are not typical user commands, but they do leave repo UUID (and if you're careful) the HEAD in the same state or similar enough state that clients don't freak out, unlike `git rebase`s that change SHA-1 of HEAD... – Hubert Kario Jan 07 '13 at 14:10
  • 2
    @HubertKario: does not sound to me as if this makes a real difference in contrast to the question ... the question is still valid for SVN, although the steps for deleting the version history in both system are technically different. – Doc Brown Jan 07 '13 at 15:04
  • @DocBrown: can't argue with that :) – Hubert Kario Jan 07 '13 at 15:11
  • Never. Never, never, never. **NEVER, NEVER, NEVER**. OK? :-) – Ross Patterson Jan 08 '13 at 03:40

4 Answers4

48

Storage is cheap, just keep it.

Sometimes you have to check if some bug was present in the pre-refactor version or reference some old piece of code.

If you really are concerned about the git checkout size then sure, you can go and delete the history, but I'd suggest starting a new repo in this case and leave the refactor commit in old one, so that when you really need it then you can easily connect them.

A git specific note: if you don't want the history for current checkout (because you just want to compile the project or create patches for current problem) you can use --depth=1, then git won't clone any history. Second thing: you can create an --orphan branch that won't share any history with other branches in repo, you can then clone only this branch and its history omitting all other objects in remote git repo.

Hubert Kario
  • 574
  • 4
  • 7
  • 14
    so in short, the answer is "never", just archive it if it gets too large – radai Jan 07 '13 at 14:45
  • 1
    Another git specific possibility to split the old history, retaining the possibility to rejoin it if needed: http://git-scm.com/2010/03/17/replace.html – matt Jan 07 '13 at 22:38
19

My "rule of thumb" about the lifetime of version history in any kind of VCS: keep the version history alive as long as you have to maintain that specific software.

For example, I am working here with a product which is older than 10 years and maintained and evolved constantly. Our subversion repo for that product has about 500MB, but actually that is "peanuts". Having the complete log available over the whole product lifetime was often very useful to understand things which happened some time ago in the past.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
2

I would suggest that you keep entire history of git commits as they help one keep logs and maintain history of major and minor changes. But I would like to suggest forking of code to different repository once major update is released thus adding only minor updates or bug fixes to older versions and focusing majorly on new major version.

This help maintain a good development structure and also help one scales down the rate at which repository grows. This is the major revision management structure which is followed by many open source projects.

Akshay
  • 161
  • 1
  • 6
  • 3
    That may be the right point in time *if* one wants to delete older history, but is it really worth the hassle? Version 2.0 of most software products is based on the files of version 1.0 (assumed we are not talking of a complete rewrite). IMHO it makes fully sense for each file to have quick access to the complete log over the whole lifetime 1.0, 1.1, 1.2, 1.3, ... 2.0, 2.1 ..., which you don't have when you cut the log artificially at 2.0. – Doc Brown Jan 07 '13 at 15:09
1

I'm a Mercurial guy, I also use a little git.

I can tell you that in Mercurial editing / removing history is discouraged, but not impossible. Everybody lives calm with this way of doing things and I think it is a better way to go. Why edit the history unless you screw up?

Git enables you to edit history, but that doesn't mean you should. This creates problems for people, nothing really good comes out of it except a tidier history, but you shouldn't care as long as you keep your commits reviewable. My perception is that with Git, people can go OCD with the history editing power.

If you absolutely have to, however, never-ever-ever-ever modify history after pushing, you will make people mad.

dukeofgaming
  • 13,943
  • 6
  • 50
  • 77