"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: got reintegrate
To:
Evan Silberman <evan@jklol.net>
Cc:
gameoftrees@openbsd.org
Date:
Tue, 15 Oct 2019 09:30:57 +0200

Download raw body.

Thread
On Mon, Oct 14, 2019 at 03:11:12PM -0700, Evan Silberman wrote:
> 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

You won't have to use it because you don't have to toggle the option :-)
The command-line option was deprecated in SVN after a heuristic was added
which toggles the option automatically. Users would, understandably, often
forgot to pass the option and then 'svn merge' would do the wrong thing.

But "reintegrate" still exists in SVN's implementation and as a user-visible
concept. 'svn merge' chooses between the 'sync' and 'reintegrate' merges
internally, depending on the "direction" of the merge, relative to which
branch was derived from the other.
This is documented in 'svn help merge' and SVN's reporting output does
mention the term "reintegrate" when it is used, so it's still very much
a user-visible thing.

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

That's certainly true.
And I recognize that 'reintegrate' is not a very common term.
But creating new names should be a last resort. We're not doing
anything other version control system aren't already doing!

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

Backout exists as 'fossil merge --backout' and as 'hg backout'.
The term is also is used regularly in the OpenBSD project even while
working with CVS (where the actual "backout" operation maps to an
invocation of 'cvs up -j X -j Y' or 'patch -R').

In addition to reusing existing commands which exist in other tools,
we can name commands after concepts or vernacular already in use.
E.g. 'got stage' is such a case. There is precedent because new Git users
will be told things like "Use 'git add' to stage your changes for commit"
(which makes me cringe every time I hear it).

Apart from "merging a branch", I can't think of a commonly used term for
"reintegrating a branch". And a merge with an implied direction of the
flow of changes doesn't exist as such in Git or Hg, only in SVN.

> > So I still believe that "reintegrate" is our best choice.
> 
> It may be!

I'm still open to other suggestions. But lacking the possibility of just
calling it "merge", I don't think we'll be happy all around with whatever
term we choose.