rebase -i is a manual operation. I think you would have to squash all the commit you want to remove.
You can rewrite your initial commit with filter-branch: › Remove all commits before a particular one, and make that one (ID or TAG) the initial $ echo ID > .git/info/grafts $ git filter-branch (source: http://documentation.debian-projects.org/software/git-core/) But I don't see how you can easily backup the removed part and still keep a connection with what you keep. In six months, you would probably be able to push the new history to the backuped one and rewrite the history there to reconnect the sequence of changesets (probably with another graph point, see https://git.wiki.kernel.org/index.php/GraftPoint). Also, because you rewrite the history, all the commit IDs will change. You will have to match the local branching points to the new commit ID to rebase the local work on each workstation. On Oct 3, 9:23 am, canna <c.ne...@gmail.com> wrote: > sorry to get back to you only now, holidays.... > > I do git gc all the time but I don't see any improvement afterwards > > Peter - I never used rebase, so I'm sorry if my question sound a bit > naive, is rebase something that you can do in one local repo and than > push the changes to the main repo, and than pull the changes to all > the other developers repos? > > On Sep 30, 10:49 am, Peter <liuhui...@gmail.com> wrote: > > > > > If you really want to remove old commit, you can just use "git rebase -i" > > >http://book.git-scm.com/4_interactive_rebasing.html > > > pick fc62e55 added file_size > > pick 9824bf4 fixed little thing > > pick 21d80a5 added number to log > > pick 76b9da6 added the apply command > > pick c264051 Revert "added file_size" - not implemented correctly > > > # Rebase f408319..b04dc3d onto f408319 > > # > > # Commands: > > # p, pick = use commit > > # e, edit = use commit, but stop for amending > > # s, squash = use commit, but meld into previous commit > > # > > # If you remove a line here THAT COMMIT WILL BE LOST. > > # However, if you remove everything, the rebase will be aborted. > > # > > > <http://book.git-scm.com/4_interactive_rebasing.html>"The last useful thing > > that interactive rebase can do is drop commits for you. If instead of > > choosing 'pick', 'squash' or 'edit' for the commit line, you simply remove > > the line, it will remove the commit from the history." > > > On Thu, Sep 30, 2010 at 3:47 PM, Peter <liuhui...@gmail.com> wrote: > > > You could try to run "git config --global gc.auto 100" on your repo > > > machine and work machine. > > > > "If the number of loose objects exceeds the value of the gc.auto > > > configuration > > > variable, then all loose objects are combined into a single pack usinggit > > > repack -d -l." > > > > On Thu, Sep 30, 2010 at 2:08 AM, Adam Prescott > > > <mention...@gmail.com>wrote: > > > >> My understanding is that git will handle running "git gc" for you when > > >> you have a fair amount of stuff it can clear up (I've seen it do this > > >> automatically, personally, but I could be wrong). So even if the > > >> answer is "no", it might not be the answer to the question, "has 'git > > >> gc' ever been run?" > > > >> -- > > >> 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 > > >> git-users+unsubscr...@googlegroups.com<git-users%2bunsubscr...@googlegroups > > >> .com> > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/git-users?hl=en. > > > > -- > > > liuhui998 bloghttp://liuhui998.com > > > -- > > liuhui998 bloghttp://liuhui998.com -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
