git workflow draft

[Stephen Kelly]

Michael Pyne wrote:

> An easy way to solve duplicates is to disable sending commit mails for
> branches other than master, but I personally dislike that solution as it
> would result in mailing lists like #kde-commits not receiving any emails
> until the branch is fully landed on master. (I hate to say it, but imagine
> a security mistake on ksslsocket.cpp in commit 88 of a 121-commit rebase
> branch -- is everyone on #kde-commits going to review that deeply into the
> commit chain?)

If someone writes 100 commits and pushes them without review then that's a 
social problem. First of all I can't imagine a clean branch that could be so 
big. Surely that would end up being a 10 commit push, some more work, a 
push, some refactoring, a push, a feature, a push, more refactoring, a 
feature, a push, etc. Do we really think that having large topic branches 
which contain really only one topic that makes sense only to push in one go 
will be a normal situation?

People who are interested in ksslsocket will see the commits.

> In addition as Andreas Pakulat mentioned in a response to a
> rebase-workflow in kde-scm-interest, this completely deletes the fact that
> the development happened in a branch at all (we could simply retain the
> old solid/make-it-cool ref so we don't lose that history, but that would
> make the repository correspondingly larger).

The assumption that all of the history is useful to have by definition was 
called into question. I suggested creating useful history so that all 
history in the release branches is useful.
 
> A lot of this debate hinges on how we want email-based review to work
> however (to be clear, kde-commits is not the only recipient of email for
> each git commit, the CIA.vc web service also receives email for each
> commit). If we want to avoid huge email bombs then we need to either use a
> merge-based workflow in general, or have some other technical solution to
> allow for a rebase-based workflow, such as your idea regarding lumping
> everything into a simple notification email (although this means CIA.vc
> and possibly things like Commit Filter wouldn't work... :( )
 
I guess we're writing emails at the same time here, but just to have it in 
another place, I don't see 'email bombs' being a problem, but a convenient 
grouping of stuff I'm interested in, and stuff I'm not interested in in 
bigger lumps.

Another important point I think is that 'topic branches' will not 
necessarily be normal, but exceptional. Most KDE developers are used to 
commit early commit often, and that might translate into 'push early, push 
often', so we'll end up seeing 2 or 3 commit pushes and very few monsters. I 
rarely push more than 10 commits and very rarely if ever have pushed more 
than 20.