On Fri, Apr 27, 2012 at 04:06:57PM +0000, Spear, Raymond (Mission Critical Linux) wrote: > 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?
If you don't have any patches on top of what's upstream in the master branch, this should suffice: $ git remote update $ git reset --hard origin/master > 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 -- Ademar de Souza Reis Jr. Red Hat ^[:wq! _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
