Thanks Thorsten for your clear words, yes, it sucks to see people messing up the history, merging local branches and then pushing them to gitorious. I personally see another problem in the way changes that are merged appear in the history: The merge date is there, but the commits associated to it can be hidden somewhere down in the history. This is a very bad state when it comes to bughunting (bisecting).
Every fgdata contributor who creates complicated xml/shader files should be able to understand basic git workflow as well... Chris ThorstenB wrote: > On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: >> The master branch of fgdata has become messed up. A number of commits >> have become duplicated and some undone (they exist in the history but >> their effect is gone from HEAD). > > It has happened again, fgdata history is messed up. It looks as if my > last commits (6d46fe7, f722671) were applied to fgdata multiple times > now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even > see how where these originated (looks as if I had pushed them multiple > times). Only the gitorious.org history shows that these were indeed not > pushed by me: > > https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 > > https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 > > Can we please make it a requirement that _local_ merge operations must > not become visible on our public repository, so _everyone_ has to > "rebase" before pushing anything? > > The only merge/branch operations that should be visible in our public > repo should be those that affect public branches (release branch > creation/merges etc). > > There's really no reason why other people should see that user XYZ has > merged his local branch 1-15 times with gitorious, before pushing back. > It only results in the git history becoming unreadable. And apparently > it results in more issues. > > If you compare simgear's or flightgear's history with fgdata's history, > you'll see how nice and readable a git history can be - since obviously > (almost) everyone pushing to sg/fg knows hows how to rebase. > > Resolving merge operations locally, to reorder and cleanup the history > is really simple - and only requires a few seconds. If you have > uncommited changes in your local directory, you can temporarily stash > them - so that "rebase" won't complain. > > For fgdata: > git stash > git rebase origin/master > git stash pop > > (And for simgear/flightgear: > git stash > git rebase origin/next > git stash pop > ) > > It is also a good idea to check the git history (gitk) before pushing to > gitorious: you can read and double check your own changes a final time - > and also check the history for local merge or funny duplication issues. > If you're having local Git trouble (like duplications), *please* ask > before pushing to gitorious. > > cheers, > Thorsten > > ------------------------------------------------------------------------------ > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
