git workflow draft

[Michael Pyne]

On Wednesday, February 16, 2011 22:31:31 Stephen Kelly 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.

That's actually a really good point, especially in terms of ways to avoid the 
disadvantages I mention -- front-load the review for large branches just as we 
already do with ReviewBoard.

> People who are interested in ksslsocket will see the commits.

You're thinking of CommitFilter. I'm thinking of the kde-commits mailing list 
(i.e. people who didn't *know* they were interested in ksslsocket until they 
saw a "strange" commit).

> > 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.

Either way is an assumption, but only one of these assumptions involves 
deliberately discarding data. ;)

What specifically do you mean by "creating useful history" though? i.e. what 
should be done additionally in a rebase workflow to get the useful history you 
refer to?

> 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.

I actually quite agree with you here for the vast majority of topic branches. 
But it also mitigates one of the disadvantages I mentioned in merging (the 
cluttered history), as there won't be too many active branches outstanding at 
any given time, and therefore there shouldn't be large problems with tons of 
branches at once anyways.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110216/cb53d583/attachment.sig>