Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Always pass the config as an explicit constructor parameter#1993

Merged
dscho merged 5 commits intomaingitgitgadget/gitgitgadget:mainfrom
explicit-configgitgitgadget/gitgitgadget:explicit-configCopy head branch name to clipboard
Sep 8, 2025
Merged

Always pass the config as an explicit constructor parameter#1993
dscho merged 5 commits intomaingitgitgadget/gitgitgadget:mainfrom
explicit-configgitgitgadget/gitgitgadget:explicit-configCopy head branch name to clipboard

Conversation

@dscho
Copy link
Member

@dscho dscho commented Sep 1, 2025

This is necessary so that the project config is reliably passed through, and the defaultConfig is not used by mistake.

This PR is stacked on #1994 and needs that to be merged first.

Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho requested a review from webstech September 1, 2025 23:51
@dscho dscho self-assigned this Sep 1, 2025
@dscho dscho marked this pull request as draft September 2, 2025 13:22
@dscho dscho changed the base branch from main to v1 September 3, 2025 18:10
@dscho dscho changed the base branch from v1 to main September 3, 2025 18:10
@dscho dscho marked this pull request as ready for review September 3, 2025 18:10
baseCommit?: string,
): Promise<ProjectOptions> {
const config: IConfig = getConfig();
const config: IConfig = defaultConfig;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be passed as a parameter?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, of course!

Copy link
Member Author

Choose a reason for hiding this comment

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

(And sorry for making such a mistake, in my defense, I thought I was still in similar-looking test code, where we do want to use the defaultConfig for reproducible testing.)

Copy link
Contributor

Choose a reason for hiding this comment

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

No problem. Will this be going away?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. Sorry, I forgot to force-push.

Copy link
Contributor

Choose a reason for hiding this comment

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

Will this be going away?

Sorry for not being clear. I was wondering if ProjectOptions might go away in the future. It was making GitGitGadget specific decisions but you have added config features that should handle the specific oddities of ggg. For a generic user, the ProjectOptions contains passed values and values from the config project section.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh yes, absolutely. The config handling should all be unified. I mentioned this elsewhere. (I forgot where. There are so many PRs by now. I'm so sorry!)

Definitely lots of opportunities for cleaning up after all that stuff is done, especially to remove the remnants of a CLI interface (GitGitGadget started out as my personal Bash script and for some time I tried to keep them in sync and then I tried to make GitGitGadget fulfill the role of the Bash script by having a compatible CLI interface. But that was a mistake and only lead to needlessly complex code.)

Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member Author

dscho commented Sep 5, 2025

Force-pushed.

Range-diff
  • 1: a0244a6 ! 1: 39c86ed ProjectOptions: do not allow the config to be passed implicitly

    @@ Commit message
     
         Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
     
    + ## lib/patch-series.ts ##
    +@@ lib/patch-series.ts: export class PatchSeries {
    + 
    +         const publishToRemote: string | undefined = undefined;
    + 
    +-        const project = await ProjectOptions.get(workDir, headCommit, cc, basedOn, publishToRemote, baseCommit);
    ++        const project = await ProjectOptions.get(config, workDir, headCommit, cc, basedOn, publishToRemote, baseCommit);
    +         if (rangeDiff) {
    +             options.rangeDiff = rangeDiff;
    +         }
    +
      ## lib/project-options.ts ##
     @@
      import { commitExists, git, revParse } from "./git.js";
     -import { IConfig, getConfig, projectInfo } from "./project-config.js";
    -+import defaultConfig from "./gitgitgadget-config.js";
     +import { IConfig, projectInfo } from "./project-config.js";
      
      // For now, only the Git, Cygwin and BusyBox projects are supported
      export class ProjectOptions {
    +     public static async get(
    ++        config: IConfig,
    +         workDir: string,
    +         branchName: string,
    +         cc: string[],
     @@ lib/project-options.ts: export class ProjectOptions {
              publishToRemote?: string,
              baseCommit?: string,
          ): Promise<ProjectOptions> {
     -        const config: IConfig = getConfig();
    -+        const config: IConfig = defaultConfig;
              let upstreamBranch: string;
              let to: string;
              let midUrlPrefix = " Message-ID: ";
    +
    + ## tests/project-options.test.ts ##
    +@@ tests/project-options.test.ts: test("project options", async () => {
    +     expect(await repo.commit("C")).not.toEqual("");
    + 
    +     const options2 = await ProjectOptions.get(
    ++        defaultConfig,
    +         repo.workDir,
    +         "test-project-options",
    +         ["Nguyễn Thái Ngọc Duy <pclouds@gmail.com>"],

@dscho dscho enabled auto-merge September 5, 2025 08:06
@dscho dscho merged commit 272e1d1 into main Sep 8, 2025
6 checks passed
@dscho dscho deleted the explicit-config branch September 8, 2025 05:33
github-actions bot pushed a commit that referenced this pull request Sep 8, 2025
github-actions bot pushed a commit to Bassamx93/gitgitgadget that referenced this pull request Sep 8, 2025
…itgadget/explicit-config, 2025-09-08))
dscho added a commit that referenced this pull request Mar 4, 2026
GitGitGadget's GitHub Actions all implicitly use the
[`defaultConfig`](https://github.com/gitgitgadget/gitgitgadget/blob/153badfc78153bb25d10e0e0d40c2cb3924d7f1b/lib/gitgitgadget-config.ts#L3-L45)
that hard-codes the configuration of the OG GitGitGadget that supports
the Git project (and the Git project _only_).

However, for a long time there have been feature requests and musings
towards using GitGitGadget also for other projects.

GitGitGadget already _does_ have some beginnings of a support for other
projects, e.g. the `IConfig` interface. With these changes, that
interface gets extended a little, a validator is added that can verify
whether or not an arbitrary object conforms to that interface, and then
new inputs are introduced, accepting this (JSON-encoded) configuration
as a user-provided string. The idea is that a project-specific fork of
https://github.com/gitgitgadget/gitgitgadget-workflows/ contains this
configuration in the `gitgitgadget-config.json` file in a dedicated
`config` branch, from where it is synchronized via a GitHub workflow to
the repository variable called `CONFIG`.

This somewhat non-trivial setup allows the config to be conveniently
tracked via Git, updated via Pull Requests, validated via GitHub
workflows, and still to be used in a trivial manner in the main
workflows via `${{ vars.CONFIG }}` (as opposed to having to play games
with multi-branch checkouts or `curl`'ing a file from a different
branch).

This PR is step number 2 in that direction. Step number 1 was to
register the [`cygwingitgadget` GitHub
org](https://github.com/cygwingitgadget/) for experimenting with
GitGitGadget support for a different mailing-list-based project than
Git: Cygwin.

That org is where I experimented with this change as well as with all
the others leading up to
gitgitgadget/gitgitgadget-github-app#7.

This PR is stacked on top of #1993 and #1994
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.

2 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.