[Kdenlive-devel] Git workflow

[Mikko Rapeli]

On Mon, Nov 07, 2011 at 03:00:33PM +0100, Alberto Villa wrote:
> On Mon, Nov 7, 2011 at 9:56 AM, Mikko Rapeli <mikko.rapeli at iki.fi> wrote:
> >> Reverting sets of commits is definitely not a solution.
> >
> > Yes it is. If a set of commits breaks other functionality, those patches
> > should either be fixed or reverted. That's how Linux kernel is maintained.
> 
> This is not a good point to discuss with a FreeBSD developer.
> 
> Just kidding. ;)

Which is why I have had problems with NetBSD: bad breaking commits were left
in the CVS tree instead of reverted once users started complaining.

> > There's nothing wrong in reverting a set of patches, asking the author to fix
> > them, and applying a fixed version later on.
> >
> > This gives the tree maintainer some options to keep the master branch in
> > releasable state.
> 
> Which is what the integration branch is made for. Reverting means
> you'll have less occasions to test new features/fixes; it means you'll
> have to revert the whole set of commits instead of just finding what's
> wrong and fix it. And leads to Git history mess.

Sometimes commits, say a new feature or rewrite, looks good and passes initial
tests and is merged to master. Later on users find that it causes problems
and tree has other fixes that maintainer would like to release.

Then reverting the patches is an option which IMO should be used.

Git history can be a mess, as long as it's history and it's not changed to look
pretty. I don't see the problem with reverting changes. Thorough testing
usually does not happen until users use the code.

I do use git daily at work and in freetime :)

-Mikko