From: Evan Silberman <evan@jklol.net>
Subject: Re: got reintegrate
To: Stefan Sperling <stsp@stsp.name>
Cc: gameoftrees@openbsd.org
Date: Mon, 14 Oct 2019 15:11:12 -0700

Stefan Sperling <stsp@stsp.name> wrote:
> 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.

Me too!

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

FWIW I'm in that boat. And evidently if I were to start using and
relearning SVN today I might never use the word 'reintegrate' as a
command:

~$ svn --version | head -2
svn, version 1.10.3 (r1842928)
   compiled Apr  5 2019, 18:59:58 on x86_64-apple-darwin17.0.0
~$ svn help merge | grep -- '--reintegrate'
  --reintegrate            : deprecated

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

I was going to ask why this struck you this way then I got the picture
while explaining it to myself. (The term in the git context might be
better if it were "fast-forward-to".) In any case I don't think
fast-forward is a particularly more accessible choice than reintegrate.

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

In the specific case of Got, you have perfectly good reasons to expect
that your target audience has used other VCS before and will hope to
find some familiar operations behind familiar names. That said, I think
to optimize too heavily for familiarity is to miss an opportunity (that
eventually will pass) to consider the name of each operation from
scratch. "backout" is not (I believe) a command in CVS, SVN, Darcs, Git,
or Hg, so it wouldn't be unprecedented in this codebase to pick a name
nobody's used before.
 
> So I still believe that "reintegrate" is our best choice.

It may be!

Evan Silberman