On Mon, Oct 12, 2015 at 1:44 PM, Alec Warner <anta...@gentoo.org> wrote: > > > On Mon, Oct 12, 2015 at 3:58 AM, Rich Freeman <ri...@gentoo.org> wrote: >> >> On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> > >> > It is, however, worth repeating that in git, commits are entirely >> > separate from pushes and are very (as in, extremely!) cheap, while >> > pushes, particularly if properly repoman-checked, are obviously much >> > more >> > expensive. >> >> Each commit really should be able to stand on its own all the same. >> >> They should all be able to pass a repoman check. > > > I guess in some ideal world I sort of agree; but in practice I think > workflows exist that involve people messing around in their local repo until > they get stuff right, then running repoman at the end and pushing the result > (that is kind of the whole point of having a local staging repo.)
I think the best practice here really depends on the nature of what you're working on. For most software the right way to handle such things is to either: 1. If you're just doing multiple iterations on one true logical change, rebase your commits into a single commit once you have it right. You could extend this into a few commits in some cases as long as they can stand on their own. 2. Do all the work on a side branch and do a merge commit into the master branch. Then master still has a history where every commit (along one side) works. This is the best approach for the development of major features which necessarily will not be complete for extended periods but where the details are still useful. #1 is likely to be most appropriate for the Gentoo repo in most cases. -- Rich
