[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?

[Jed Brown]

On Tue, Mar 5, 2013 at 10:19 PM, Sean Farley <sean at mcs.anl.gov> wrote:

> > This does not appear to namespace the branches and it looks like you have
> > to edit .hg/hgrc for each remote that you want to track. It is quite
> > different from namespaced branches/bookmarks.
>
> Sure, but only the person wanting to pull has to add a path to their
> .hgrc which is extremely easy to understand and do.
>

It's two places in a file, compared to 'git remote add my-remote-name
the.url:repo'.

The remote bookmarks are still not namespaced so I still can't safely fetch
from all remotes before going offline (and even if I'm online, many
operations are relatively slow). After 'hg pull somewhere' (rather than
pulling a specific branch/bookmark), I don't have a way to keep track of
which bookmarks came from where. At least divergent conflicts give warnings
"divergent bookmark yyy stored as yyy at default", but other bookmarks are
automatically fast-forwarded and new bookmarks are added (I can't find an
option to treat everything as a "divergent" bookmark even when it could
fast-forward. I'd much prefer that.)

This is much "too global" management of bookmarks if you ask me.


>
> You misunderstand me. I think branches/bookmarks are pretty cool and
> useful. I also think using changeset evolution (to achieve the shared
> garbage-collection of git's unrefed heads) is cool, too. But those
> workflows
> are advanced and require each user of the repo to conform, without
> buying all *that* much more than the fork / pull-request model.
>

With a git repository, those branches really do not affect the user. Try
this

$ git clone https://github.com/gitster/git
$ cd git
$ git log --graph --pretty=oneline
*   7799588faa2a8071da8ef047c87f9a1520fb8903 Merge git://
github.com/git-l10n/git-po
|\
| * 5e93cd307bdb98809bb0aa3bfb2c0306131f3654 l10n: de.po: correct
translation of "bisect" messages
| * a295fe616f162de5f1640fe95d0060554e12e12a l10n: de.po: translate 5 new
messages
| * 48cc7c1b24ea5c9bf59ad98bd308b5fd5b3802d1 l10n: de.po: translate 35 new
messages
* | 4d0d0c3c59800e07d899e53121902833e3fd0cc7 Git 1.8.2-rc2
* |   06d67b876642822828596b0b38cda2f61d438335 Sync with 1.8.1.5
|\ \
| * | e6363a4992637267ef212d7c709ede17d4122e0d Git 1.8.1.5
| * | 8b1bd024154f0ee0d71a6befe9bbd96462e76abc Make !pattern in
.gitattributes non-fatal
| * |   1d38c6971dd1a4b054d90b7ae4c9de5400b9d818 Merge branch
'wk/user-manual' into maint
| |\ \
| * | | 5e2485846dacb5acd3b6cd084e246c7c9a6d5a13 Documentation/githooks:
Fix linkgit
* | | |   443d803e0dacd0a1c6700503689f3cd95751aba1 Merge branch 'maint'
|\ \ \ \
| |/ / /
| * | | 8d44277d91989ad2b37d4908096bd5256d6390c4 Update draft release notes
to 1.8.1.5
| * | |   6f0c33666300ccf95eb4b4e723e07a3c588d12db Merge branch
'ef/non-ascii-parse-options-error-diag' into maint
[...]
$ git branch
* master

I'm oblivious to the presence of other branches, but there are over 300
that I can find by

$ git branch -a | head
* master
  remotes/gitster/ab/gitweb-use-same-scheme
  remotes/gitster/al/mergetool-printf-fix
  remotes/gitster/ap/log-mailmap
  remotes/gitster/ap/maint-diff-rename-avoid-overlap
  remotes/gitster/ap/maint-update-index-h-is-for-help
  remotes/gitster/ap/merge-stop-at-prepare-commit-msg-failure
  remotes/gitster/ap/status-ignored-in-ignored-directory
  remotes/gitster/as/api-allocation-doc
  remotes/gitster/as/check-ignore

So I can easily browse ongoing projects ('git log gitster/ap/log-mailmap')
and I can work on them ('git checkout ap/log-mailmap', hack away...) but
unless I'm directly interacting with a branch, I'm totally unaffected by
those ongoing projects and never see them in my normal workflow ('git log',
'git branch', etc).

If we are going to consider allowing topic branches to "cook in next" for a
while (to get tested in interaction with the rest of the system) before
being merged to a stable branch, then we need to keep these bookmarks
around somehow, yet it's unacceptable for them to intrude on normal
workflow. I still haven't heard of a viable plan in Hg's roadmap.


> Instead, what I am suggesting is taking incremental steps in that
> direction. The fork / pull-request model is pretty darn simple and
> allows each developer to work with either workflow (or even some
> hybrid). If Barry doesn't want to ever change his habits, then it's
> fine. Others could pull, clean-up, and merge his work.
>
> On top of that, new developers (including people more comfortable with
> subversion / cvs / centralized development) won't be bombarded with too
> much and can work in their own fork as they please.


In all cases, the contributor workflow is (a) create topic branch, (b) hack
away, (c) push to personal repo and submit pull request OR (c') email patch
series to list. The distinction in all these possibilities is how we as
maintainers manage review, testing, and release of those contributions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130305/aeef3b3f/attachment.html>