From: Stefan Sperling Subject: Re: got reintegrate To: Evan Silberman , gameoftrees@openbsd.org Date: Mon, 14 Oct 2019 09:42:42 +0200 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.