On Sat, Oct 12, 2019 at 05:51:40PM +0200, Stefan Sperling wrote:
> If you want to suggest an alternative, please try to pick a term already
> in use by CVS, Git, Mercurial, SVN, or Fossil.
> 
> The most general term for this operation would be a "merge", but I want to
> reserve 'got merge' for a command which would create commits with 2 parents.
> 
> Hg additionally has "graft" but it uses this term to describe cherry-picking,
> which is a different operation already mapped to 'got cherrypick'.

I have tried to find additional terms we could use instead of 'reintegrate'.

Hg has a 'transplant' command which looks more like cherry-pick or rebase,
and which has been superseded by the 'graft' command already mentioned above.
I don't think we should use this term, especially since Hg is phasing it out.

There is git's "fast-forward merge" where a reference is moved ("forwarded")
to another commit, which is exactly what the proposed 'got reintegrate' does.
Git's UI makes this feature available with as 'git merge --ff-only'. 
I would prefer this to be a separate subcommand. We don't yet have an
implementation of what a regular 'git merge' would do. We cannot add an
optional "ff" mode to a non-existent 'got merge' command. And I don't
want to implement merge-commits until the day we find a real need for them.

We could use 'got fastforward' (got ff) to appeal to people familiar with
Git, however this might confuse everyone else (granted, 'reintegrate' might
be confusing people who have never done branching and merging with SVN).
The proposed implementation of 'reintegrate' will "forward" the base-branch
of the work tree, not the branch given on the command line. So using this
name would also require branch parameters to be swapped: The user's work tree
would be on branch 'newbranch' and they would be "fast-forwarding" 'master'
to this branch, rather than being on 'master' with users asking the tool
to "reintegrate" 'newbranch' into 'master'.

Unlike "fast-forward", the term "reintegrate" fits nicely with flow diagrams
people would (or rather, should ;-) use when discussing branching/merging
strategies:

             +--------------+ branch
            /                \ <-- reintegration merge
 master ---+------------------+----

Coming up with new terms (such as "adopt", "join", "fold", "slurp", "meld")
is easy but has the already mentioned downside that all users will find such
terms unfamiliar at first sight.

So I still believe that "reintegrate" is our best choice.