merging chg into contrib tree?

[Matt Mackall]

On Mon, 2015-11-23 at 23:50 +0900, Yuya Nishihara wrote:
> On Fri, 06 Nov 2015 18:24:15 -0500, Pierre-Yves David wrote:
> > On 11/02/2015 10:35 AM, Yuya Nishihara wrote:
> > > https://www.mercurial-scm.org/wiki/ChgPortingPlan
> > > 
> > > My preference is:
> > > 
> > >   1. how to merge?
> > > 
> > >      reorganize as 10+ patches (base, pager, setenv, sendfds,
> > > ...)
> > 
> > I would be happy to drop a full history of chg converted to
> > dispatch the 
> > file in the right place. Having full history is always useful when 
> > digging into bugs.
> > 
> > >   2. source layout
> > > 
> > >      (frontend)
> > >      contrib/chg/Makefile
> > >                  README
> > >                  chg.c
> > >                  hgclient.[ch]
> > >                  util.[ch]
> > >      (server)
> > >      hgext/chgserver.py
> > >      mercurial/osutil.c <- chgutil.c
> > 
> > Why having chgserver.py in hgext? as we know we want chg as a first
> > class citizen, could have the server logic in core?
> 
> I made an experimental mercurial repository that includes most of the
> chg
> changes.
> 
> https://bitbucket.org/yuja/mercurial-chg-porting/#chg
> 
> Still it doesn't pass all test-check-*.t and chgserver.py is placed
> under
> hgext/. Several manual tweaks will be necessary.
> 
> C sources are formatted by the following rule plus dirty regexp.
> 
> https://bitbucket.org/yuja/chg-porting/src/55b740b2db9a/.clang-format
> https://bitbucket.org/yuja/chg-porting/src/55b740b2db9a/Rakefile#Rake
> file-160
> 
> So, do we really want to go this way? or fold patches?

I still think we should import it wholesale. Either in one commit or a
small series of clean patches.

The goal of importing the history would be to make archaeology easier.
But it's actually impossible to do this in a way that doesn't create a
fictional history and thus obscure the archaeology efforts we're trying
to aid.

For instance, Yuya's import slaps several hundred sequential commits
down on top of the default branch in a way that makes it look to a
future investigator as if the entire project stagnated between 2011 and
2015 and the only person who did any work was Yuya. Obviously this is
not the case. To -actually discover what happened to the repo- you have
to go to the mailing list archives (if they exist) and find the
discussion that says "we pulled in Yuya's fake history".

Two other possibilities exist. First, we could simply pull in the chg
repo and rename the code into place with a merge. This is way worse,
because now you have spans of the project where most of the code
vanishes. Bisection nightmare, never mind the archaeology. We did this
once with the purge extension. I have regrets. In fact, I don't think
anyone's ever cared about the pre-history of purge.py, but it's stuck
us with an entire extra repository root forever.

Lastly, we could replay the history of both projects into a third repo
where we pretended chg was developed in-tree all along. Of course, this
is a (really big) lie too, so is no aid to archaeologists either. Also,
it's an enormous hassle.

Also, at no point in these artificial histories are we actually
asserting the test suite passes or code was reviewed or trusted or any
of the normal things that the appearance of a commit in the main repo
currently represents.

Making a mess of the project's history so we can annotate a few files
cleanly is not a particularly good trade-off.

Compare that to a single commit that says "pulled in project X revision
Y from URL Z". That's what's actually happening. It'd be nice to put Z
somewhere we can depend on existing in the future for posterity so that
people can annotate pre-history, but the value of that will decrease
pretty rapidly over time.

-- 
Mathematics is the supreme nostalgia of our time.