On 5/21/14, 4:00 , Jacek Becla wrote: > K-T > >> + Rebasing history that has already been pushed is problematic. I can >> see this for u/ branches, but it's more questionable for tickets/ >> branches. It messes up other people's history. > > I thought: > a) we are now creating a "backup" branch through a hook > on every rebase, and rebasing has been OK'ed/accepted, > have I misinterpreted anything? We're not doing this yet in LSST/ hierarchy (I still have to implement the 'hidden/' refs that Simon figured out), but we will be by the end of May. ...[snip]... > >> I think "clean history" is somewhat in the eye of the beholder. >> I think the main way to maintain a useful history is to never merge from >> master/next/integration into a ticket branch. Rebasing of the sort you >> have described seems to me to just avoid parallel branches, at possibly >> significant cost. > > If we do the messy work in the next/integration branch, > I believe cleanly applying that work to master would be > a non-trivial job. But maybe I can be proven wrong. > > My main goal is to find a way to keep it clean enough so that > we can always relatively easily track down what was done > when and how and by whom. With very convoluted history it > is getting exponentially harder with every messy merge. > +1 In concert with atomic commits ("one commit == one feature") and usable commit messages [1, 2], you can catch up with development just by reading the log. 'git bisect' also prefers linear history (though we haven't used it much yet). [1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html [2] https://wiki.openstack.org/wiki/GitCommitMessages -- Mario Juric, Data Mgmt. Project Scientist, Large Synoptic Survey Telescope Web : http://research.majuric.org Phone : +1 609 933 1033 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1