"private-kvp" merge reverted other changes since November.

[Christian Stimming]

Am Mittwoch, 14. Mai 2014, 10:10:18 schrieb Geert Janssens:
> On Tuesday 13 May 2014 21:35:58 John Ralls wrote:
> > On May 13, 2014, at 9:01 PM, Mike Alexander <mta at umich.edu> wrote:
> > > That's what I do.  I rebase my branches onto master each time it is
> > > updated.  This seems to work well and keeps the tree much simpler.
> > 
> > That's the SVN way. We discussed this back in March [1] and decided
> > that we're not going to do that anymore. If you want to revisit that
> > you need a better argument than "that's the way I've always done it",
> > considering that the Git community at large doesn't seem to consider
> > it a "best practice".
> 
> It seems to me the git community is not against rebasing private
> branches before pushing them to a public repository (provided their
> branch point was never pushed earlier). Whether we should mandate this
> for gnucash is debatable.
> 
> I have seen suggestions to prefer short-lived topic branches. So I'm
> going to think out loud here. If a topic asks for a long term topic
> branch, perhaps the topic is not well chosen or could be split in
> smaller sub topics which each go on their own branch.

If we discuss the personal preferences again: My preference clearly is for 
shortly lived branches and frequent rebasing of private branches. The "ladder" 
history looks magnitudes harder to read to me, compared to a linear history of 
rebased commits. (Not to mention the "railway merger", but that's probably a 
different topic.) 

I'm convinced by the arguments to have two long lived branches, maint and 
master, but I'm not convinced to allow more than those branches for longer 
times. I'd expect people to rebase their private and/or feature branches 
frequently. For me, it would make it much easier to understand what the new 
features really are and what the relation to the master branch are.

Regards,

Christian