[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Sean Farley]

Jed Brown writes:

> On Tue, Mar 5, 2013 at 8:09 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>
>> And this is why I think git makes things more complicated than need
>> be.
>>
>
> By keeping remotes namespaced and having exactly one branching
> mechanism?

By not forcing any branching? All of what you have described so far can
be accomplished, easily, with forking / pull-requests and the
remote-branches extension today [1]. You can get even more fancy
after Atlassian implements non-publishing repos.

>>  > As I mentioned before, bookmarks in hg are much more in-your-face than
>> git
>> > branches. Up until now, we have not allowed multiple heads in any PETSc
>> > repositories. Can we do it without confusing people?
>>
>> I disagree about them being in your face. I think you're making this
>> workflow more complicated than need be.
>>
>
> To start with, 'hg log' shows you all bookmarks. The normal user following
> petsc-dev will issue
>
> $ hg pull -u
> $ hg log
>
> to see what is new. The fact that many normal commands show all the
> bookmarks makes them disruptive. The ability to customize those commands or
> modify them to restrict to the current bookmark is besides the point
> because the default is overwhelming.

See my above recommendation. You don't need bookmarks or anything else
fancy. Just remote-branches, really.

>>  As for having multiple heads, I wouldn't recommend that workflow for
>> this group just yet.
>
> Okay, so you're retracting your recommendation that Barry push on a
> bookmark?

I didn't mean to imply that Barry should use bookmarks (in fact, he
shouldn't). Only that you could achieve most of what you're describing
about git's branches, etc.

I like the fork / pull-request model because,

1) it's simple to understand
2) everyone can clean up their history at their own pace
3) a developer can pull another dev's repo (and keep track of it) with
the remote-branches extension; but it isn't necessary
4) it's a minimal (if any) disruption of people's current workflow, yet
gains a lot of features mentioned before (cleaner history, more
stability in petsc-dev, etc.)

[1] - http://mercurial.selenic.com/wiki/RemoteBranchesExtension