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
