Hummm... excuse me if this is an obvious question with an easy answer but I do not know it.
Since the install of autotest into production uses is a git clone of the repository, what is the easiest way for folks who are only "using" autotest and not making source changes to pick up this history change? Thanks, ray spear -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Chris Evich Sent: Friday, April 27, 2012 7:54 AM To: autotest Subject: Re: [Autotest] [ANNOUNCEMENT] - Autotest history rewritten 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). -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
