"private-kvp" merge reverted other changes since November.
christian at cstimming.de
Sun May 18 14:20:24 EDT 2014
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  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
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.
More information about the gnucash-devel