What happened to the work that went into breaking up fgdata into manageable chunks?
New flightgear git users are faced with an initial download of about 10gb just to get started. It seems to me that this current problem is another good reason to re-arrange fgdata. So much work went into it last year, all to be scuppered by what seems to have been a unwillingness on the part of a few individuals to agree on the implementation. Alan -----Original Message----- From: Tim Moore Sent: Saturday, September 22, 2012 8:34 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] fgdata trouble On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB <bre...@gmail.com> wrote: > On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: >> The master branch of fgdata has become messed up. A number of commits ... > 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). > I haven't looked at this latest problem in detail, but you can do as much damage rebasing as merging. I suspect the real problem here is rampant cherry-picking. I happen to think merging, at least when pushing local changes to the public tree, is a lot better than rebasing, because then a given set of changes only appears in a single commit in the repository. > 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. Yes, pushing a branch that has numerous merges from master/next is unpleasant. There are many pages on the Web describing git workflows that avoid rebasing and keep a clean history. > > 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. Except that I never rebase before pushing to sg/fg :) I should qualify that: I do interactively rebase before pushing, often rearranging commits and divying them up to make more sense. But I *never* rebase onto a different head than the one on which I started the branch. > > 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. Can't argue with that. > > 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 > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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
