merging chg into contrib tree?

[Yuya Nishihara]

On Mon, 23 Nov 2015 15:42:52 -0600, Matt Mackall wrote:
> 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.

Ah, this made me clear why I felt that would be a "mess", thanks.

So, let's start with a few clean patches. I wanted to eliminate dead codes
before merging.

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

We might be possible to make an extension that will help archaeology,
by viewing two unrelated repositories as unionrepo and hijacking "annotate"
flow.