On Fri, Apr 27, 2012 at 10:54:05AM -0400, Chris Evich wrote: > On 04/26/2012 01:29 PM, Lucas Meneghel Rodrigues wrote: > > After much thought about this subject, I went ahead and pushed a non > > fast forward update to the autotest repo, rewriting the project's > > history effectively, assigning authorship where it belongs and getting > > old cruft from the svn days. > > > > We decided to do it because: > > * It's more fair to the over 200 contributors we had over the years > > > > $ git shortlog -s | wc -l > > 202 > > > > * Stats do matter, with a more properly written history it'll be easier > > to generate relevant stats for people, using git. > > > > So, let's consider this a much needed housekeeping initiative, and sorry > > for the inconveniences. > > > > Now, for 3rd party, I ask you guys to rebase. I did all my rebases using > > git format-patch and re-applying the patches cleanly on newly created > > branches, and you might well do the same (unless there's some fancy > > ninja git tool to do it without using patches at all). I'll be available > > to assist you, should you need any help. > > > > Thank you! > > > > Lucas > > For anyone less talented with git (like me), here's some more details: > > Effectively what's happened is upstream autotest's entire history won't > match any forks or branches you have now. The commit text is all mostly > the same, but the indexes will have all changed. > > However (at least this is my understanding), the repo on github still > retains all the old history plus sha sums. The effect will be, any > branches you have currently are now pointing off in la-la-land - > somewhere that will never receive any further updates or even be looked > at. It will do this silently though, which is why big announcements are > being made. > > In order to get your github forks and local branches back on-track, you > basically need to re-jigger all of your local changes onto the "new" > upstream indexes. This way, your history lines up with the new history > instead of the old. However, since the indexes won't match anymore, the > easiest way to do this is with e-mail formatted patches: > > > 1) Make a backup of your local autotest repo (just in case). > 2) Git clone a whole new fresh copy from > [email protected]:autotest/autotest.git > 3) Re-setup any repo. customization you've made (refer to your backup > copy's .git/config if needed). > 4) Nuke your github fork (if you have one), setup your remotes, and push. > 5) Using the backup copy as a reference, make new branches for > everything you care about (and push to github fork if you have one) > 6) Again using your backup, for each branch, use git format-patch > against the old master. You probably want to store these patch sets in > separate directories to make life easier. > 7a) If your local branch was recently rebased: > On the new clone's recreated branches, use git am to apply the patch > sets from #6 (and push to github fork if you have one). It'll probably > complain about indexes not matching, but this is okay. > 7b) If your local branch hasn't been rebased in a long time, do 7a but > with 'git am -3' (a 3-way patching) to allow you to resolve the > conflicts "easier" - you'll probably find using git merge-tool will help. > 8) You should end up with all your old local branches retaining their > commit messages and changes, but re-aligned (rebased) with the "new" > history. > > Assuming this is confusing, take your time and read through the relevant > man pages to refresh your understanding. If you totally screw it up a > few times, rely on the backup you made to start over. If you get > horribly stuck and need help, don't be afraid to ask here or on IRC > (info on the wiki).
Below is a different approach, which I consider simpler but requires a bit more understanding of git: First of all, if you run git pull on top of your curren branch, it'll break with tons of conflicts. In this case, just run: $ git reset --hard and things will get back to normal (as before git pull) Now for the "migration" procedure, assuming origin points to the upstream git repository (the default). (DISCLAIMER: untested) 1. Make a backup of your current git repository just in case 2. run "git log" and identify your patches which are not-upstreammed; 3. Once your "fork point" SHA1 has been identified (let's say, you have 3 local acommits and the first one is identified by 13ae8b39), you extract your patches with git format-patch. Example: $ git format-patch 13ae8b39 If you haven't run git remote-update or git pull since Lucas pushed the rewrite, you can extract these with git format-patch origin/master (origin/master will be still pointing to the old upstream ref). 4. You now have your patches as files (000n-<patch-title>) 5. Now let's sync with the new remote ref: $ git remote update $ git reset --hard origin/master 6. Now apply your patches: $ git am 00*.patch $ rm -f 00*.patch Repeat 2-6 for every branch on your copy (replacing origin/master). 7. Review if everything is correct (run a few remote updates, pull, rebase, etc) and then remove your backup. Cheers - Ademar -- Ademar de Souza Reis Jr. Red Hat ^[:wq! _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
