From: Mark Jamsek Subject: Re: got reintegrate To: Stefan Sperling Cc: Evan Silberman , gameoftrees@openbsd.org Date: Tue, 15 Oct 2019 19:53:15 +1100 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 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. >