Unclear how to preserve draft phases when pulling from a Git repo

[indygreg]

I've been using Sapling for a few hours and love it. Thank you for rescuing me from having to use Git :)

But I ran into some quirks with phases and Git repos.

I manually edited .sl/config to add a [paths] entry for a local Git repo using a file:// URL. I then sl pulled it. It looks like Sapling made the pulled commits public.

I have a few questions:

1. Can I mark a Git repo as non-publishing? In Mercurial, you would add a [phases] publish = False. But I tried adding this to the .git/config and this didn't work.
2. Same question as above, but for remote Git repos I don't control. e.g. github.com. Perhaps there's a feature request in here to mark a remote repo as non-publishing without the remote advertising that? And maybe an e.g. sl pull --draft flag to force incoming changesets into a non-public phase?
3. How do you edit phases using sl? sl phases exists and appears to behave like the Mercurial command. But when you run it to adjust phases, it looks like the functionality is disabled:

$ sl phase --force --draft 411df877c6b1::
(phases are now managed by remotenames and heads; manully editing phases is a no-op)

sl help on remotenames and heads doesn't tell me how to adjust phases. And the docs for sl help phase and sl help phases appear to be wrong, implying you can modify phases via sl phase.

[quark-zju]

With 71e889a049f95187fb475531214de1895f1107e6 (included in the latest release but not the first release), The remotenames.publicheads config specifies public remote bookmarks and is default to remote/master, remote/main. Other branches are draft by default. We'll update the help pages as a follow up.

[bolinfest]

@indygreg latest release also has GitHub Enterprise support for sl pr and sl ghstack.

[rbehrends]

I found that remotenames.publicheads (and many other remotenames configs) cannot by set in the user level config because the %include builtin:git.rc at the top of the local config overrides it. Is this intentional? Even if intentional, this should probably be documented, as it can be very confusing why the setting doesn't take.

[indygreg]

Thanks for the update! I can confirm that the latest release made changesets draft instead of public for the non-main remote. So that fixes the blocking issue I had.

I'll let a maintainer close this issue whenever they want.

Thanks for the heads up about GitHub Enterprise support! My corporate GitHub account cares very much about that :)