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
|
