The pull-request template used by Hubkit managed projects allow to provide which issues were fixed, but more then often I forget to close these issues. Instead these issues should be detected and automatically be asked if these should be closed (or at least some).

Yes I know GitHub provides auto closing closes #xxx but this doesn't work with markdown templates 😥

The BranchSplitsh service doesn't have any functional tests, using the local testing repositories this should be made possible.
But Splitsh is required to be installed, so GitHub workflows this might be challenging.

Currently it's tested manually.

Next week the HubKit will be moved to it's own organization, for now the codebase itself will not renamed to prevent too many BC breaks.

HubKit will moved to https://github.com/hupkit (with a p, instead of b)
If the upgrade fails due to this redirect, please update manually.

Check and warn if the commits contain WIP, swears or other useless stuff.
Related to rollerworks/search#194 (comment)

Description
Currently when you merge your own pull request you get asked if you want to remove the "working branch" as this gets easily forgotten. But as with #85 you get asked multiple questions.

Instead I propose to automatically remove the "working branch" (if fully merged of course and not the "master" or versioning branch). And only keep it with the new option --no-cleanup (or a better name).

HubKit version(s) affected: 1.6-BETA7

When you run the config-init command (or checkout the _hubkit branch) and have a config.php file that is ignored by Git (as is the case for HubKit itself) the config.php file will overwritten.

And the same is true for other files, although unlikely I still consider this a serious problem. Both commands should check if these files exist (and are ignored by .gitignore) and warn that these will be temporarily moved to named file like hk~config.php, once done these files moves are moved back.

As the the config-init command is designed with the purpose of initializing the configuration branch this requires a finalizing command to clean-up everything once done.

Effectively editing/initializing the configuration is as follows:

1. inti-config or edit-config (new command)
2. Editing the configuration, adding files, etc
3. save-config verifies the configuration (by crashing if broken 😅 ), checkout the previous branch (before editing started),
   and restores backed-up files.

In the rare case the temp files still exist fail hard with an error, and require to solve this manually.

[WARNING] It appears there is gap compared to the last version.
           Expected one of : 0.6.2, 0.7.0, 1.0.0-BETA1, 1.0.0

Instead this should fail and tell a release already exists for this tag as it's properly a user error.
And suggest a possible next version (which is valid).

When a PR is merged with the --squash option, the "merge" commit doesn't show up in the changelog. It looks like this commit done by the github api is not a real merge commit to git.

git log --merges ... used for the changelog command does not list that commit.

KnpLabs/php-github-api@5eb55ce Example commit has only one parent if merged with --squash

I was also looking at symfony commits but somehow they can have a squash merged with a commit with 2 parents -> symfony/symfony@cea5ebc

 [OK] Pull request has been merged.

 [WARNING] The Git working tree has uncommitted changes, unable to update your local branch.

 Split repository now? (yes/no) [yes]:
 > 

Splitting is not possible here because the local branch is not updated, this split would have no effect.

Dry run shows what would have been done without actually doing it, which makes using this command for the first time much safer.

The big day is almost here. HuPKit v1.2.0 final.

But running split-repo revealed a fatal bug (#124), and I'm pretty sure this isn't the last one.

• Add tests for
  • SwitchBaseHandler
  • SynchronizeConfigHandler
  • InitConfigHandler
  • EditConfigHandler
  • CheckoutHandler
• Update vendors
• Run all commands
• Ensure proper testing coverage
• Ensure no major PHPStan errors
• Ensure Github workflows are working
• Small things, CS etc.

Running upmerge with a branch named 1.x doesn't work as expected. The x in this case needs to be the highest number possible (considering the other version branches).

Once the pull-request review API is stable enough to be used, this should be detected when merging a pull-request.

Maybe in time this can replace the current label system which is based on Symfony's development workflow.

Pull request #59 introduced to the ability to detect and automatically close related issues. In the meantime this feature was added natively to GitHub itself.

I propose to remove this functionality from HubKit and use the GitHub auto detection instead.

Problem: When using upmerge with a monolith repository you still need to split the repository manually after each upmerge operation.

Proposal: Automatically (or ask to) split the repository after an upmerge operation, unless the option --no-split was provided.

Description
The take command defaults to the master branch, in many projects this has (or is changing to) main or versioned branch names instead.

Instead of changing the default to main the command should instead use the current branch-name as the base, and check if the branch is either a common name like: master, main, devel, develop, or an acceptable major.minor version syntax.
And ask for confirmation if this is not the case (to prevent mistakes).

In fact, the current situation is misleading:

$ hk take 290
Working on rollerworks/search (branch main)

fatal: The command "'git' 'checkout' 'upstream/master'" failed.

Reminder for myself. https://developer.github.com/changes/2017-04-07-end-merge-methods-api-preview/

Documentation building is currently broken and cannot be fixed easily, as Markdown has reached it's limits for what this project needs it's best to switch to RestDoc instead.

I'm working on this, so stay tuned.

HubKit version(s) affected: 1.0

Description
This pull request failed to merge because the commit was using the GitHub web interface, and no user was selected.
rollerworks/PasswordStrengthValidator#39

Possible Solution

        foreach ($commits as $commit) {
            if (! isset($commit['author'])) {
                $authors['web-flow'] = $authors['commit']['author']['name'] ?? 'web-flow'; // web-flow is the default user for GitHub web edited commits.
            } else {
                $authors[$commit['author']['login']] = $commit['author']['login'];
            }

            $message .= $commit['sha'].' '.explode("\n", $commit['commit']['message'], 2)[0]."\n";
        }

Additional context

Print-r dump of the commit.

Array
(
    [sha] => 0a4acd92e95a6d5df7f08a955af3aee10b03f02b
    [node_id] => MDY6Q29tbWl0MzIyNTU4MDI3OjBhNGFjZDkyZTk1YTZkNWRmN2YwOGE5NTVhZjNhZWUxMGIwM2YwMmI=
    [commit] => Array
        (
            [author] => Array
                (
                    [name] => Cédric Martineau
                    [email] => [email protected]
                    [date] => 2020-12-18T11:04:46Z
                )

            [committer] => Array
                (
                    [name] => Cédric Martineau
                    [email] => [email protected]
                    [date] => 2020-12-18T11:04:46Z
                )

            [message] => Fix regex for specials characters
            [tree] => Array
                (
                    [sha] => 27221ca879d57cc0e6353b9f827e6f5276c4feab
                    [url] => https://api.github.com/repos/tino299/PasswordStrengthValidator/git/trees/27221ca879d57cc0e6353b9f827e6f5276c4feab
                )

            [url] => https://api.github.com/repos/tino299/PasswordStrengthValidator/git/commits/0a4acd92e95a6d5df7f08a955af3aee10b03f02b
            [comment_count] => 0
            [verification] => Array
                (
                    [verified] =>
                    [reason] => unsigned
                    [signature] =>
                    [payload] =>
                )

        )

    [url] => https://api.github.com/repos/tino299/PasswordStrengthValidator/commits/0a4acd92e95a6d5df7f08a955af3aee10b03f02b
    [html_url] => https://github.com/tino299/PasswordStrengthValidator/commit/0a4acd92e95a6d5df7f08a955af3aee10b03f02b
    [comments_url] => https://api.github.com/repos/tino299/PasswordStrengthValidator/commits/0a4acd92e95a6d5df7f08a955af3aee10b03f02b/comments
    [author] =>
    [committer] =>
    [parents] => Array
        (
            [0] => Array
                (
                    [sha] => 98a72a0a8a2f599afee137666ae0c4faceee25d3
                    [url] => https://api.github.com/repos/tino299/PasswordStrengthValidator/commits/98a72a0a8a2f599afee137666ae0c4faceee25d3
                    [html_url] => https://github.com/tino299/PasswordStrengthValidator/commit/98a72a0a8a2f599afee137666ae0c4faceee25d3
                )

        )

)

Note. I will try to fix this later today 👍🏼

Description
When using TravisCI the build-status is shown in the status table of the merge command but GitHub checks are not shown here?

Example

| Item                      | Status | Details                   |
|---------------------------|--------|---------------------------|
| Full CI process / PHP 7.1 | OK     | Successful in 2m          |
| Full CI process / PHP 7.2 | OK     | Successful in 2m          |
| Full CI process / PHP 7.3 | OK     | Successful in 2m          |
| Full CI process / PHP-QA  | Failed | Failing after 1m — PHP-QA |
| Scrutinizer               | OK     | No new issues             |

Description
Some repositories use 'master' as the final branch for upmerging while newer repositories use 'main'

It should be possible to detect what the correct branch is, though a git config (core.main-branch) .
If absent use 'master' for compatibility (can be changed in v2.0).

https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/

Currently the documentation has a number of problems that need to be resolved.

• No way to see all navigation
• Local configuration isn't really explained, as new hook scripts will be placed this needs better coverage
• Configuration schema isn't directly accessible, only though other pages (see first point)
• Authentication for GitHub enterprise should in the configuration page

$ hk release alpha
Working on rollerworks/search (branch master)

 Provided version: 1.3.0-ALPHA1

This is not correct, the resolved version should be 2.0.0-ALPHA1

Release command detects when there is a gap between versions (compared to the last one in for the major version). It would be nice to also known which versions "are" expected.

This should be as precise as possible, so a gap in the minor should only inform minor not patch.

Say the following versions exist

v1.0.0-beta1
v1.0.0-beta2
v1.0.0-beta3
v1.0.0-beta4
v1.0.0-beta5
v1.0.0-beta6
v1.0.0-beta7
v1.0.0
v1.0.1
v1.1.0

And I release 1.3.0 I should see:

It appears there is gap compared to the last version.
Expected: v1.2.0

Please check your input or confirm is this intended.

Expected candidates for (with current version list shown above):

• 1.1.2 -> 1.1.1
• 2.0 -> none
• 1.2.1 -> 1.2.0

Don't allow any command when a rebase is in progress.
Else you end-up with a really angry person 🙂

HubKit can only be used "properly" from the Git root-directory, but the detection seems broken.
This not a big issue as it does work, but branch-alias detection is incorrect when you are in a sub-directory 😅

Since HuPKit v1.2 it's possible to store repository configuration (repository splits mainly) either locally (in the _hubkit branch) or globally in the config.php located with the installed HuPKit installation.

In v1.3 a new feature was (is) added to allow configuring the main-branch, and additional features are planned as well.
Note that the main-branch can only be configured with the local configuration, and the same will apply to new repository configuration as well (with the exception of branch-level configurations).

For HuPKit v1.4 I'd like to propose to deprecate the global repository configuration (not adapter configurations, as tokens cannot be stored within version control 😄 ) and remove global repository configuration completely in v2.0.

This makes the documentation easier to understand and explain and prevents outdated configuration among team members.
Note that it's not required (but recommended) to push the _hubkit configuration branch to the remote central repository, so only keeping this branch locally still works as normal.

Please let me know of any objections, thanks 👍🏼

When you make a new minor/major release the composer.json branch alias should be updated afterwards. I tend to forget this, so it would make sense to add this feature to the release command.
And automatically commit and push.

Note: It should be offered to update the branch alias, as not always this possible or there could be commits that weren't pushed yet. In relation to #9 this is disabled when there are custom scripts used.

When a configured prefix directory does not exists a fatal error is thrown, the problems happens with tag synchronizing.

• Check for all existing prefixes before the operation (warn if missing, and ignore if confirmed)
• Allow different split configurations per branch-source

The changelog and release command will only list items in a changelog group when the pr was merged with HubKit (and not the GitHub "merge button"). This needs to be made more clear.

HubKit version(s) affected: v1.2.0

 Error Output:
  ================
  remote: error: refusing to update checked out branch: refs/heads/main
  remote: error: By default, updating the current branch in a non-bare repository
  remote: is denied, because it will make the index and work tree inconsistent
  remote: with what you pushed, and will require 'git reset --hard' to match
  remote: the work tree to HEAD.
  remote:
  remote: You can set the 'receive.denyCurrentBranch' configuration variable
  remote: to 'ignore' or 'warn' in the remote repository to allow pushing into
  remote: its current branch; however, this is not recommended unless you
  remote: arranged to update its work tree to match what you pushed in some
  remote: other way.
  remote:
  remote: To squelch this message and still keep the default behaviour, set
  remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
  To file:///var/folders/6h/r8zg1bc56q77p71lnj38ln1w0000gn/T/hubkit/stor/repo_afd97f6cec2c5a25a2f235183fe557e5a70804f0
   ! [remote rejected]   b8e0efe1c4c745dbe022371dfa485f221caa7998 -> main (branch is currently checked out)
  error: failed to push some refs to 'file:///var/folders/6h/r8zg1bc56q77p71lnj38ln1w0000gn/T/hubkit/stor/repo_afd97f6cec2c5a25a2f235183fe557e5a70804f0'

I'm already working on a fix.

Webmozard/console doesn't play nice with long descriptions (no idea's for improvement 😅), so keep the usage documentation separate (for now).

We had this in Gush (mainly for contributors), but since GitHub allows to update pull-request of a contributor (unless disabled) it makes sense to have it in Hubkit also.

This makes it easier to help contributors without having to perform complex Git operations or resorting back to local Git merges and closing a pull-request (like Symfony's GH does).

I just merged a pull request with the --squash option but still the commits were retained as-is, nothing was squashed.

Not sure if this a bug in Hubkit or the GitHub API end-point.

Currently when a new release is made all the tags are pushed which in some rare cases results in an unresolvable fatal error. Instead only the new tag must be pushed, and no other tags.

Category [feature] (feature, refactor, bug, minor, style)? should be displayed as Category (feature, refactor, bug, minor, style)? [feature]

When creating a new release I should be able to use the next "version fragment" automatically
hubkit minor and get the next logical minor version for this branch.

The command already validates if there are gaps so getting the next version should not be a problem.

This should support patch, minor, major, beta, rc and alpha. And increase that fragment.
For beta this means the current beta version is increased, if there there is no current beta release then increase the minor version and set beta to 1.

Problem: Sometimes a release requires the execution of a script for some additional process, like updating the meta-data version number, updating the changelog release date, etc.

Solution: Detect if a ./.hubkit/[pre|post]-release.php file exists and execute it.

When the pre-release script updates versioned files, a new pull-request will be created (and merged, as a normal GitHub merge) so changes can be traced.

The post script should be used for release workflow components (like publishing a pre-written article in an external CMS, Tweeting an announcement, etc.) when versioned files are changed these need to be commited and pushed manually.

Description
Allow to skip a release for a split-repository which doesn't have any new commits.

This feature can be enabled using either a repository config (schema-version 2) or using a using a command option.
--skip-empty=[force-]yes|no.

Add a rebase command for pull-request to update the remote and local branch (if any) to skip some manual steps.

Problem: The self-diagnose command fails when run from a Git repository without the upstream remote being set. This problem is caused by GitHub::autoConfigure() which is called whenever a Git repository is detected.

For install I solved this by adding the remote automatically, but for other cases this should be taken care of properly. It's just a small issues, but it should be fixed.

Solution: Only run GitHub::autoConfigure() when RequiresGitRepository is implemented by the CommandHandler. Making this method required for Git enabled CommandHandlers, and ignored otherwise.

Hi,
Is it possible to add a way to choose the head remote ? (and choose something different than upstream)

I can suggest you using the composer extra field to make configuration (like that it would be repository-wide only.