Can we switch off LGTM reviews?

[ahmadawais]

I really like GitReflow and am planning to devise it in my personal workflows. But most of the times, till the beta, I am the only one building and gitting as we speak. I would like an option for LGTM reviews to be switch off when working on individual git repos until there are more members.

[codenamev]

We added a feature in the latest release that allows you to set a "minimum number of approvals". If you set this to zero it should give you the behavior you are looking for. I would also suggest you set this up for each project so that you don't make it a global setting :wink:. You can do this with the local flag from the root of your project.

git reflow setup --local

When it asks for the minimum number of approvals, just enter 0. Let me know if this doesn't work and I'll re-open this issue.

[ahmadawais]

@codenamev I have selected 0 in setting up the Git Reflow for the very first time. I again used the --local parameter to setup 0 but when I do a git reflow deliver it says This is the current status of your Pull Request. Are you sure you want to deliver?. And I have to say Y to get it working.

Could there be a better workflow for individual devs trying to keep a better PR based feature branch workflow with reflow?

[codenamev]

Our documentation is in major need of TLC. We do provide some configuration options here. What you're looking for is git config --add "reflow.always-deliver" "true"

[ahmadawais]

@codenamev But that would make it true in all the cases... while I do have some repos where I need LGTM reviews. I was wondering if it could be possible on a more project by project basis. Maybe in a future release or two?

Happy with what I see now :)

[codenamev]

i believe if you don't provide --global to git config it will use your project config file

[ahmadawais]

^Sure! I for now am going with writing Y when it asks for it. Will let you know if I change my mind.

[pboling]

@codenamev so git reflow already supports project level config?!? I was under the impression that neither gli gem nor git-reflow supported that yet.

[simonzhu24]

@pboling I believe that reflow was built with the intention of supporting project level config, but I am not sure if the workflows were entirely tested:

The answer lies in: https://github.com/reenhanced/gitreflow/blob/master/lib/git_reflow/config.rb

Take the add command for instance:

Reflow first checks if you have --global flag, if you do, it will modify ~/.gitconfig. If you have the --local flag instead, it will modify .git/config in your local repo. If you have neither, you are changing key-value pairs in ~/.gitconfig.reflow.

Note: These 3 options are only present in the add command. Reflow set and unset removes the --global flag and only has 2 options, toggling between .git/config and ~/.gitconfig.reflow (Perhaps a bit inconsistent?). When Reflow finally reads values (most important part), it uses the get command. It runs git config --get which follows the git default configuration levels (looks in local first, then system, and finally global):

1. Local (.git/config)
2. System ($(prefix)/etc/gitconfig)
3. Global (~/.gitconfig)

TLDR (Summary): Git Reflow reads from your git configuration file. If you want to configure reflow settings on a project level basis, you can leave your global settings (~/.gitconfig and ~/.gitconfig.reflow) the way it is, but you will have to specify the new settings on a project level basis. (ie: you will have to copy the key/value pairs over to .git/config and replace them with the values you want for that particular project. Reflow should read the values from a project level git config first.

@codenamev does this sound correct?

[codenamev]

@pboling we have supported project level config for quite some time now (see 800874d78843721e88b7c5044c31b963525b6785). I use it on several projects without any issues.

The magic is in git reflow setup --local which you run from a project you want to setup in a different way than your global git-reflow configuration. With the --local flag, we add the value <remote_user>/<remote_repo_name> to the config array using the reflow.local-projects key and store this in your ~/.gitconfig.reflow file (see GitReflow::GitServer::GitHub#initialize). We have a method on the GitServer base class (project_only?) that is used throughout the code to check if you've set up the current project this way.

@simonzhu24 Config.set and Config.add serve two separate purposes. Long story short, set is used to ensure the value replaces any existing, and add will insert a duplicate. We use add exclusively for adding an include.path entry for the .gitconfig.reflow file in the user's main .gitconfig (in case they are already using include.path), and for managing the reflow.local-projects entries.

[simonzhu24]

@codenamev Thanks for the reply! I think it makes everything a lot clearer! ^_^

It seems like I am mistaken about the way reflow reads configurations, it reads the configurations from ~/.gitconfig.reflow which stores the configuration for all local repositories adding <remote_user>/<remote_repo_name> to the config array! (I thought it read them from .git/config in each repo.)

I know that the README.rdoc already mentions this indirectly, but it might helpful to explicitly mention something like:

Git Reflow Setup has 2 flags. --enterprise and --local, where enterprise sets up reflow to an enterprise github account and local allows you to configure your reflow settings on a per project basis. These setting changes will be saved in ~/.gitconfig.reflow adding <remote_user>/<remote_repo_name> to the config array for each repository.