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