Issue

I'd like to know which branches are stale (remote branch merged and deleted) so I can clean up my local repository.

Version

N/A

Expected behavior

The listing should add the information in front of each line (with a color code).

Bonus: allow to select the branches for deletion or to delete stale branches from gut obliterate (see which makes more sense)

Issue

gut burgeon tries to create branch master.

Version

No applicable yet

Expected behavior

It should fail miserably

How to reproduce

Run gut burgeon

Issue

Some parameters to CI jobs can't be guessed. Let's have Gut prompt the users for those.

Version

Not applicable yet

Expected behavior

When configuring a CI job, it should be possible to ask the user for one of the parameter's value.

Example:

{
  "ci": {
    "jenkins": {
       "build": {
         "server": "personal",
         "uri": "/jobs/gut",
         "body": {
           "branch_or_tag": "$currentBranch",
           "myParameter": "$ask(myParameterName)"
         }
       }
    }
  }
}

When running gut ci, Gut should prompt the user for the value of myParameterName.

Specs

Issue

It should be simple to checkout master, the version branch, the feature branch and the base branch.

Version

Not applicable yet

Expected behavior

The command switch should accept the parameters:

• -m to switch to master
• -v to switch to the version branch
• -f to switch to the feature branch
• -b to switch to the base branch

Issue

Gut is currently not tested, let's fix that.

Version

Not applicable yet

Specs

Version

Not applicable yet

Expected behavior

There should be a command to copy the current branch into the system's clipboard.

How to reproduce

Not applicable

Additional information

You can use the package copy-paste.

Issue

The README is quite empty right now. It should give a glimpse of what Gut does.

Version

Not applicable yet

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Specs

Specs

Spec here

Issue

Using gut switch -r 'whatever' doesn't find branches that only exist on the remote.

Version

Not applicable yet

Expected behavior

The remote branches should be shown in the choices too!

How to reproduce

Run gut switch -r <regex> where regex matches a branch that only exists on the remote.

Issue

Some repos don't have associated projects in bug trackers (micro-services for example). This means the commit templates may contain different project ids.

Gut should allow users to configure the template so that the project is prompted when committing.

Version

Not applicable yet

Expected behavior

Maybe add a syntax like this: "commitMessageTemplate": " (${prompt:projectId}-$ticketNumber)"
Gut would then prompt the user for the projectId when committing.

How to reproduce

Use gut execute

Issue

Currently, when cd-ing to repository flukteplukte, one might have to type *ukte for the search to match. This is a shame as * is more complex to type on lots of keyboard layouts than letters.

Version

Not applicable yet

Expected behavior

I'd expect ukte to match my repository as I'm quite sure no other will match this.

Auto-surrounding the search by * would make the search wider and simplify typing in most cases. It'll have the drawback of sometimes matching too much (ex: gut now matches Gut-test) but most of the time the pros outweigh the cons.

Specs

Issue

Running gut replicate --help does not show the arguments to the method.

Version

Not applicable yet

Expected behavior

A documentation like all other commands get.

How to reproduce

Run gut replicate --help

Specs

Issue

It is way easier to type a command when there's tab completion. Currently, no tab completion has been implemented, meaning Gut is behind Git on this point.

Version

Not applicable yet

Expected behavior

There should be tab completion for every parameter to every command in Gut.
You can split this in multiple PRs of course, for example one PR for git items completion and one for yargs parameters completion (based on parameter's choices).

Other information

I've got no preferences for the dependencies to use for tab completion but you should probably check this link.

Issue

The command audit should display the number of files that were changed.

Version

Not applicable yet

Spec

Issue

Currently, trying to create a PR on a branch that was never pushed fails miserably.
Let's remove one useless command!

Version

Add the version of Gut you're using

Expected behavior

The branch should be pushed before creating a PR.
The push should be non-blocking (don't wait until it's finished to configure the PR).
The push should only occur if the branch was never pushed before or if the local branch is above the remote branch.

How to reproduce

cd "$aRepo"
gut burgeon -d myBranch
echo toto > tata
gut pile
gut execute -m A message
gut pr

Issue

Add slack integration to query-review feature.

Version

Not applicable yet

Expected behavior

The query-review feature should ask the user if he wants to post a message on a chat (only Slack supported to begin with).
You can see how it's done in the current bash implementation here

Specs here

Specs

$gut install fails because of duplicate variable declaration

Issue

The review tool is currently extracted from the repository path but in the repository path, it is the git server that is present, not the review tool.

Version

Not applicable yet

Expected behavior

The review tool should be extracted from repository config's reviewTool attribute.

Specs before implementation
Specs after merge

Issue

The command gut execute -m 'message' fails when there is no message template in the repository's configuration file.

Version

Not applicable yet

Expected behavior

The the commit be done without suffix.

How to reproduce

Run gut execute -m 'message' in a repository:

• without a repository configuration
• with a repository configuration without commit message template

Issue

The command gut pr doesn't work when the branch has never been pushed.

Version

Not applicable yet

Expected behavior

The branch should be automatically pushed if it was never pushed before.

How to reproduce

In any repository, run:

gut switch -m
gut burgeon -n 82 -d prShouldPushFirst
# commit anything, otherwise gut will notice nothing was updated from base branch and won't try to create the PR
gut pr

Specs

The vulnerabilities added by the dependency don't look like they're going away: Kong/unirest-nodejs#113

Issue

It should be easy to jump to a repository inside the repository folder.

Version

Not applicable yet

Expected behavior

The repository should be searchable:

• full-name search like jump Gut
• incomplete name search like jump Gu
• filter by git server and/or owner jump -g github -o quilicicf Gu
• filter by incomplete git server and/or owner jump -g githu -o quili Gu
  In case multiple repositories match the search, the command should show them and allow the user to choose from them.

Other information

This method implies changing the directory, it means it must be a shell method.
It can pass all its arguments to the NodeJS app then receive the list of matching branches and parse it if it's more convenient.

The file utils is too big, let's split it in separate files (already started) and require only the parts needed.
The lodash merge performed to aggregate them adds a layer that prevent IDEs to perform auto-complete anyway which is annoying.

Issue

It should be easy to run CI jobs on a repository from Gut.

Version

Not applicable yet

Expected behavior

The repository configuration file should contain:

• a Jenkins account with credentials to use Jenkins' API
• a CI section with an object which keys are the job's name and value an object describing the HTTP call to do to run the job

There should be Gut-provided variables, e.g. Gut will replace $<variable name> by its value.
The provided values should be at least the current branch, and each part of the branch.
There could also be a special variable to make Gut prompt the user for it (for example $ask(toto)).

Example configuration:

{
  "accounts": {
    "jenkins": {
      "username": "your username",
      "password": "your password"
    }
  },

  "ci": {
    "jenkins": {
      "package": {
        "uri": "https://jenkins.mycompany.com/job/package/build",
        "body": {
          "parameter": [{
              "name": "branch_or_tag",
              "value": "$currentBranch"
            },
            {
              "name": "version",
              "value": "$currentVersion"
            }
          ]
        }
      }
    }
  }
}

Issue

Using gut execute without staged changes fails without clearly explaining why.

Version

Not applicable yet

Expected behavior

Either a specific message or maybe a flag to add all the files in the repo before committing and a validation between the git statut and the actual commit ?

How to reproduce

Use gut execute with unstaged changes.

Issue

When running npm audit, run a script to display repository-related metrics.

Version

Not applicable yet

Expected behavior

Example: npm audit could show the difference in numbers of eslint warnings between the two considered commits (using bisect?).

Specs before implementation
Specs after merge

Specs before implementation
Specs after merge

Issue

It should be possible to force-push BUT force-push should only be allowed on branches where only the current author has already pushed.

Version

Not applicable yet

Expected behavior

The command thrust should accept the parameter -f to force-push.
The force-push should be disallowed if:

• the commits from the base branch contain a commit from another author (might require to add something in the Gut config ?)
• the remote and the local branches are not in sync

Issue

Currently, branches that were not created with Gut don't have descriptions => no baseBranch set.
This means some Gut commands fail (i.e. audit).

Version

Not applicable yet

Expected behavior

When trying to use the branch description and it's empty, fill it! lib/utils/branches:getBranchDescription

How to reproduce

Create a branch using git, commit something, run gut audit -b => 50 commits shown. There should be one.

Version

Not applicable yet

Expected behavior

On a clean repository, it should be easy to undo the last n commits. The changes should then be either stashed or deleted permanently or just remain as is.

The specification is available here

Issue

When creating a PR, gut should write the URL to the branch's description. Then it should be possible to open, copy or display it.

Version

Not applicable yet

Specs before implementation
Specs after merge