Skip to content

Support branches other than "master" - #175

Merged
savetheclocktower merged 11 commits into
pulsar-edit:masterfrom
idleberg:feature/support-custom-branches
Jun 13, 2026
Merged

Support branches other than "master"#175
savetheclocktower merged 11 commits into
pulsar-edit:masterfrom
idleberg:feature/support-custom-branches

Conversation

@idleberg

Copy link
Copy Markdown
Contributor

GitHub has changed the default branch from master to main in October 2020, setting an example that has since been followed by its competitors. However, Atom/Pulsar packages are still stuck at using master. Publishing a package from a different branch will fail.

This PR addresses this twofold:

  1. the default branch is detected via git symbolic-ref
  2. any custom branch can be passed via the --branch flag

@idleberg idleberg changed the title Feature/support custom branches Support branches other than "master" Mar 17, 2026
@idleberg

Copy link
Copy Markdown
Contributor Author

@confused-Techie Any feedback?

@savetheclocktower

Copy link
Copy Markdown
Contributor

Sorry! Can't speak for @confused-Techie, but I know that I've been busy with other things. Poking us occasionally is 100% the right thing to do.

@idleberg

idleberg commented May 6, 2026

Copy link
Copy Markdown
Contributor Author

@confused-Techie Any news on this?

@idleberg

idleberg commented Jun 6, 2026

Copy link
Copy Markdown
Contributor Author

@savetheclocktower Can you take a look? Will #172 solves the issue?

@savetheclocktower savetheclocktower left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests pass for me locally and the code looks fine. One observation that is not actionable right now.

@idleberg, have you been able to publish packages using your modified version of ppm? That's the only other thing I would consider testing — but you've contributed before and if you've managed to prove it works, that'd be good enough for me.

Gonna approve now and land soon (probably tomorrow; will set a reminder) just in case @confused-Techie wants to take a look.

Comment thread src/publish.js
Comment on lines +280 to +283
const ref = execSync('git symbolic-ref refs/remotes/origin/HEAD', {
encoding: 'utf8',
stdio: ['pipe', 'pipe', 'ignore']
}).trim();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the first place in ppm we'd be calling execSync just to read some information. That doesn't mean I'm against it — but it does mean we should probably add something to git-utils to allow reading the same information more programmatically.

This will do in the meantime — especially since there are thorough specs.

@idleberg idleberg Jun 7, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense to me. I investigated some more and learned that npm uses @npmcli/git for its git operations. However, that delegates processes to @npmcli/promise-spawn, so the signature of the method would change and become async. Changing this would likely become a rabbit hole that should be avoided in the scope of this PR.

I could imagine creating a new git module within ppm, but I no preference whether to involve a third-party library. Generally speaking, maybe it's best to weigh in some more opinions, if you prefer to.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I had momentum on this I added some APIs to git-utils; feel free to play around with this PR and see if it would do what you need.

@confused-Techie confused-Techie left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the massively delayed response.
But overall, the idea is sound, code looks clean, and with the amount of tests added to the publishing suite I'm inclined to trust it.

If all of @savetheclocktower's comments are fully satisfied I see no reason we can't merge this in and finally get this updated. Thanks for the hard work!

@savetheclocktower

Copy link
Copy Markdown
Contributor

@idleberg, @pulsar-edit/git-utils has been bumped to 8.1.0. If you bump the version in this PR, you should be able to use the new APIs we just added instead of shelling out to get the correct branch name. Let's find out if it works as expected!

@idleberg

Copy link
Copy Markdown
Contributor Author

@idleberg, @pulsar-edit/git-utils has been bumped to 8.1.0. If you bump the version in this PR, you should be able to use the new APIs we just added instead of shelling out to get the correct branch name. Let's find out if it works as expected!

ppm still uses git-utils. I installed @pulsar-edit/git-utils as an npm alias, but it seems Yarn does not support that. Is the Pulsar tested well enough to do a proper replacement in all the requires?

@savetheclocktower

Copy link
Copy Markdown
Contributor

Whoops.

Ordinarily I'd tell you use to use the resolutions field of package.json — that's what we do in the Pulsar repo. But that's a yarn feature. Whereas the README for ppm says to use npm instead of yarn, and NPM’s overrides are a bit more complicated.

So, yeah, I'd say it's safe to move entirely to @pulsar-edit/git-utils in all requires. When we first forked git-utils, we ensured all the tests passed; and when we rewrote it from nan to N-API recently, we didn't change the tests then either. So as far as I'm concerned, it's safe to swap one for the other.

Comment thread package.json Outdated
@idleberg

Copy link
Copy Markdown
Contributor Author

The tests still fail on NodeJS 14 and 16, BUNDLED_NODE_VERSION lists NodeJS v20.11.1. Looks like an oversight, shall I open a separate PR removing those versions from the matrix?

@savetheclocktower

Copy link
Copy Markdown
Contributor

Might as well do it in this PR and add 20 to the matrix. (You've been patient enough and I won't make you put another blocker in the way!)

@savetheclocktower

Copy link
Copy Markdown
Contributor

The new failures are strange and I can only assume this is a git-utils regression after all. They seem to run afoul of repo.isWorkingDirectory — which, in the git-utils specs, assumes filesystem case insensitivity and compares the working directory thusly:

      expect(repo.isWorkingDirectory(workingDirectory.toUpperCase())).toBe(true)

Let me do some quick investigation. Sorry this has been such a pain!

@savetheclocktower

savetheclocktower commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

OK, I know what's going on. When I updated to newer libgit2, some specs started failing on Windows that I was able to get passing again by doing some path normalization (converting backslashes to slashes).

But the spec I mentioned before (for isWorkingDirectory) failed to test that method thoroughly enough. Turns out isWorkingDirectory’s normalization isn’t exhaustive enough: it does some substitution of path separators, but fails to also do realpath-style resolution. That’s important because Windows filesystems are weird and long file names can have canonical short names like RUNNER~1. So it wasn't robust enough to take an arbitrary path (like from process.cwd) and use it directly.

Currently testing a fix in CI; if it works, I'll fast-track a PR on the git-utils side, put out a new release, and bump this PR so you don't have to keep babysitting it. Stand by!

@savetheclocktower

savetheclocktower commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

@idleberg, I'm releasing you from this experiment. I am making progress over on git-utils, but it's annoyingly complicated. Feel free to return to the shell-out strategy for now, and to return to the existing git-utils without the @pulsar-edit/ prefix. (You can keep the CI matrix where it is — 18/20/22!)

Once it ships, I'm happy to revisit this and bump git-utils myself as soon as I can vouch for it.

@idleberg
idleberg force-pushed the feature/support-custom-branches branch from d370d7f to fee3e22 Compare June 12, 2026 20:29
@idleberg
idleberg force-pushed the feature/support-custom-branches branch from fee3e22 to 1714a50 Compare June 12, 2026 20:31
@idleberg

idleberg commented Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

@idleberg, I'm releasing you from this experiment. I am making progress over on git-utils, but it's annoyingly complicated. Feel free to return to the shell-out strategy for now, and to return to the existing git-utils without the @pulsar-edit/ prefix. (You can keep the CI matrix where it is — 18/20/22!)

Once it ships, I'm happy to revisit this and bump git-utils myself as soon as I can vouch for it.

I've reverted the two commits adding @pulsar-edit/git-utils and added a TODO comment for the code that should be replaced

@savetheclocktower

Copy link
Copy Markdown
Contributor

OK, you can leave Node 22 out of the matrix. :)

(This puts a deadline on migrating to @pulsar-edit/git-utils; we're on Node 20 now, so we must switch over before we bump Electron to a version that uses Node 22!)

@savetheclocktower

Copy link
Copy Markdown
Contributor

Landing this. Thanks, @idleberg, for shepherding this PR through our unreasonably long gauntlet!

@savetheclocktower
savetheclocktower merged commit 2b782ab into pulsar-edit:master Jun 13, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants