This is the mail archive of the
mailing list for the binutils project.
Re: git is live
- From: Cary Coutant <ccoutant at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, GDB Development <gdb at sourceware dot org>, Binutils Development <binutils at sourceware dot org>
- Date: Tue, 29 Oct 2013 11:12:46 -0700
- Subject: Re: git is live
- Authentication-results: sourceware.org; auth=none
- References: <877gd5iyaz dot fsf at fleche dot redhat dot com> <CAHACq4o_Lgy7G5c9rRLB1tijmEngrOn8UgsQVdrnk9j8o1=D1A at mail dot gmail dot com> <5266CCDC dot 6090803 at redhat dot com> <CAHACq4qqw4MZznnW7zAnOMW2kHEYRRyymAphoEiY1Of5Qeks8w at mail dot gmail dot com> <87iowgalle dot fsf at fleche dot redhat dot com>
> You want git rebase --onto.
> I did it using "git format-patch" followed by "git am" the first time.
> The second time I did Pedro's approach and used "git rebase --onto".
> Both of these worked great, though some manual labor is needed.
> (Actually the second time I wrote a script to automate it: using git
> merge-base to find the root of a branch and then looking up the
> corresponding commit in the new tree -- but for reasons I don't know it
> only worked for about half of my branches.)
Yeah, I tried rebase --onto for one branch, and format-patch for
another. Both worked fine, but the fetch-and-rebase approach imports a
whole commit history dating back to the beginning of time into the new
repo. It seems like it'll be easier to make sure I don't leak old
commit history from the old repo into the new one with format-patch.
I'm not sure how much I've bloated my repo just from fetching the one
branch -- presumably it's not a lot, since the content store is based
on hashes, but I might reclone and compare sizes just to see. (Maybe a
git gc will clean things up, too.)