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

[John Ralls]

On May 18, 2014, at 11:20 AM, Christian Stimming <christian at cstimming.de> wrote:

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

OK. Let's step back a bit.

First, the effect of rebasing: If one rebases a private branch and then merges it, the default is that it fast-forwards the target branch (which should be master with the policy we've agreed so far), which will erase its identity as a separate branch.
That can be prevented by adding the --no-ff option to merge, but history will look like:

         B - C - D
        /         \
     - A - - - - - E -  {master}

instead of 

        B - D - F
       /         \
    - A - C - E - G -  (master)

without rebasing. Is that really what you and Mike are looking for?

A somewhat separate issue, I have proposed three complex and extensive changes: The C++ rewrite to remove the core dependency on GLib, separation of the View and Controller code to enable easier implementation with different GUI frameworks, and moving SQL into the engine in place of QOFQuery to enable multi-user access. I expect each of those sets of changes to involve many tens of commits spread over several years; if they're ever to be completed, they're going to require more than one developer to contribute. ISTM the only sane way to coordinate all of that is with long-running branches that those several developers contribute to, which are frequently merged from master to avoid the divergence problems I encountered on private-kvp, and which are periodically merged back into master so that the main-line development doesn't go off in the wrong direction.

BUT, since those branches are, from the main repository's view, private, it should be possible to create the appearance of small feature branches by using a two-step merge back, where the person performing the merge into master creates a new branch off of the appropriate long-running branch -- which has been merged from master to resolve any conflicts -- then rebases the new branch onto master, then merges the result --no-ff into master, creating the appearance of a feature branch in the canonical repo's history. I haven't tested this, it might not work, but I think it should.

Geert suggested the other day that we could rebase the long-running branch before each merge, and that that should create the illusion of a series of short feature branches on the main repo. I haven't tested that either, but I have no reason to think that it wouldn't work. My concern with it is that it requires force-pushing to the coordinating public repo (e.g., my GitHub fork which we're using for C++) and thus some potential pain for other contributors.

So how do we want history to reflect those long-running series of change-sets, how much extra work is justified in getting history to look the way we want it, will either of the above plans do it, and perhaps most important, will they actually work?

Regards,
John Ralls