I’m just catching up on this as I plan on using Got vice git but missed the
first part of this discussion regarding ‘reintegrate’

Have I got it right that it basically syncs the master branch with the
working branch? As in you checkout a new branch to, for example, add
a new feature or fix a bug and then want to sync the master with the changes?

I apologise if I’m off the mark, I only caught the last couple messages
but am trying to get an understanding.


> On 15 Oct 2019, at 6:30 pm, Stefan Sperling <stsp@stsp.name> wrote:
> 
> 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.
>