Mark Goodwin wrote:
Russell Cattelan wrote:
Personally I don't see a reason to keep a ptools tree in lock step with
with a git tree. ...
you might not, but you're not working for SGI anymore :)
We have loads of other trees to merge stuff into other than
those on oss.
Ya I'm familiar with the complexity disguising itself as productivity.
(But I will say I experienced a much worse complexity for the sake of
Many of the internal scripts for managing this
are very intertwined with ptools. The one thing that will
really help with handling externally contributed patches is
for the primary internal SGI dev tree to become GIT based.
But not having git->ptools auto merge is not an option.
Actually if auto merge is a requirement I don't really see a shift in
policy. I don't see much difference in a ptool->git vs a git->ptools
Just because git is the birthing repo for changes, it seems like that
drawing more process into things and making change adoption
just as slow if not slower.
It seems like decoupling the process, not just switching SCM's and allowing
experimental changes to come to light sooner is what people are looking
PCP is in the same boat, just ask Nathan :)
Looking at this next week ...