On Tue, May 20, 2014 at 10:25 PM, Mario Juric <[log in to unmask]> wrote:
> On 5/21/14, 4:00 , Jacek Becla wrote:
>
<snip>
> > 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
>
>
Add another +1; having atomic and clean commits is also very helpful when
dealing with the differences between the LSST stack and its HSC fork.
It'd be a lot more work for both reviewers and reviewees, so I'm not
certain it'd be a good idea, but I'd personally be willing to try having
git history cleanliness be a part of the review, with a focus on ensuring
that commits are atomic and sufficiently explained.
Jim
########################################################################
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
