You don't need 3 years of commits.... until you do!
If you live on the wrong end of a really thin pipe you can use
git clone --depth 10
or something to limit things to recent history.
On Tuesday 28 September 2010 22:19:06 canna wrote:
> didn't anybody deal with this problem?
> I really don't understand how can it be, Git exist for a long time
> nobody needed to archive old commits (and eliminate them from the
> repository) to reduce the size of the repository and get rid of
> ancient history?
> do all Git users just push and push commits forever and ever?
> I mean who needs 3 years of changes on your hard disk? why wont you
> want to backup part of it and leave only the recent changes on your
> hard drive?
> On Sep 20, 5:57 pm, canna <c.ne...@gmail.com> wrote:
> > Hello Everybody!
> > I hope someone can help me with this because I didn't find any
> > information on that subject in the internet, and I'm struggling with
> > this for a whole two days now....
> > we're using git for a year now and the repository grow very big,
> > the main remote repository is located on a local network computer and
> > all the developers push and pull from it
> > the problem is, it's taking a lot of time for simple everyday
> > operations like pull, push, show log (TortoiseGit), check for
> > modifications (TortoiseGit) - to complete. also all the old commits
> > are irrelevant (there is no way in the world we could ever revert to
> > those commits)
> > is there a way to somehow cut off half of the repository, meaning get
> > rid of the old commits, for instance throw away all the first half of
> > year of commits in order to make the repository lighter and easier to
> > manage?
> > Scott Chacon (http://git-scm.com/) recommended his post: Replace
> > Kicker (http://progit.org/2010/03/17/replace.html). I like the idea
> > of pushing all history (old commits) to a separate ("history")
> > repository while removing the same history from the main repository.
> > unfortunately his tutorial doesn't explain how to synchronize this
> > change with the main remote repository and with all other local
> > branches.
> > we are around 5 developers, so it's still reasonable to go over all
> > the repositories of everybody and rebase every brunch in the system
> > manually if that what it's take to make it work...
> > Thank you for any help on that subject!
> > Netta
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at