Sometimes the pull request trying to get created for a branch that doesn't exist yet. Need to wait for the initial push before we can create the pull request.

this way you can do reflow start from anywhere and know that you're starting with fresh code from the latest master on origin

The README refers to master branch explicitly and a quick search of the source code shows it mostly hardcoded. What would be the best way to support a permanently configured alternative base, e.g. 'develop'? e.g. supporting an environment variable GITREFLOW_BASE or something like that.

So, if we use it, BitBucket's pull request won't be closed because gitreflow merge the pull request manually into master. After master has the new change, the pull request will become empty.

I think the workflow can be changed to:

Assuming we want to merge the branch A into master.

1. Squash all commits in A into a single commit and force push. The pull request on Bitbucket will reflect this change.
2. Use BitBucket API to merge (instead of merging manually)

In this way, we won't have an empty pull request.

I understand this might be a lot of work though.

(This workflow works for Github as well.)

In order to make the workflow faster, what do you think about not prompting to open the PR at the end of git reflow review ?

git reflow review --help doesn't list an option to turn off that offer.

Many terminals will let a user click a URL, so perhaps we could just print out the PR URL, and if the user wants to visit there, they can click it.

I'm wondering why you chose to adopt this workflow. Do you really want to get rid of the individual commits, or do you only like the simplified history? We're looking at using this tool because it closely matches our current workflow, with the biggest difference being the squashing.

It's probably a lack of understanding on my part, but I'm wondering what advantage I'm missing, since the cleaner history can also be gotten with git log --first-parent and seeing everything that was merged in a specific commit can be achieved with git show -m SHA1 (provided you do --no-ff merge commits).

This might also be something to add to the README or Wiki, since I can't be the only one wondering this.

I have stumbled into this error suddenly. Can anyone help what could be the problem.

error: undefined method body' for #<ArgumentError: wrong number of arguments (2 for 1)>`

After running git reflow review on my first branch created by reflow, I saw this error:

~/Code/dartdoc[sl-hide-exceptions] $ git reflow review
sh: /Users/sethladd/Code/dartdoc/.git/GIT_REFLOW_PR_MSG: Permission denied

It looks like I'm not able to edit my PR message, and maybe this error is why?

During the setup there was no option to specify a default commit format. I apologise in advance if I overlooked such a feature.

In my case I want to remove all the squashed commit information from the default commit text, since this info is not relevant in any case and just takes up space.

Just install the reflow gem and went through the setup. When I ran git reflow review on the branch I was working on I got the following message:
error: undefined method 'shift' for "git rev-parse --show-toplevel":String
error: undefined method 'strip' for 1:Fixnum

Did this on my PC at work so I'm not sure if that is being goofy. I wasn't able to get resnet running locally on that machine but did on my Mac at home. Cloned a copy of the work I had done at home to my work machine and thought I could push up the changes for review using reflow.

Let me know if you need more info.

Thanks,

Mike Prince

the deliver -f or deliver --skip-lgtm is no longer functional

sometimes, when you submit a PR to github, it errors. we should catch this, and ask the user if they want to retry; usually a retry seems to work. maybe even retry a few times ourselves.

Running setup when 2-factor is enabled simply tells you "Invalid username or password". If you dig deeper and comment out the rescue statement, you see the actual error which is:

error: POST https://api.github.com/authorizations: 401 Must specify two-factor authentication OTP code.

Github's guide here has some pointers on how to deal with this.

When running a git reflow deliver and the commit editor pops up, the first 2 lines are the same.

I usually am verbose about my PR messages; it's the place i do my brain dump of what i was thinking, issues I ran into, and so on. Sometimes I write nice commit messages that would work well in a changelog; others are just noise.

ideally, we'd set a flag on review command that grabs the commits we wrote and formats them in a change log for us in the PR, and presents in editor for update

Might be a good idea to flag commits when creating them to be changelog specifically; or, maybe just delete ones that are noise when submitting the PR.

However, changes can occur after a PR is submitted. So we'll want to think about what we do there; perhaps offer a direct way to regenerate the changelog, so we can at least copy in anything new.

a starting point: git log --pretty=format:"%B" --first-parent --no-merges master..branchname

Let's be verbose. We want to print every command right before we run it so there are no surprises, and so we never forget the right way to do things.

I asked Valentino about this, and his reply (a month ago now) was:

We've recently abstracted much of the git server interaction into a generic interface so we could work on a BitBucket integration (which is 90% there). We don't currently have plans to integrate with Gitlab, but would happily merge it if you'd like to tackle it. Take a look at our github implementation as a reference. It's in the same directory as the base.rb

If you decide to take on the challenge feel free to ask away with any questions and I'll help where I can. Otherwise open an issue for it as a feature and we'll let the community decide on it.

Unfortunately we probably won't have scope to work on this ourselves where I'm currently working so opening this issue as a feature

Thanks,
Peter

This feature needs to account for both the external contributor (the one doing the forking) and the members of the project (that do the merging of the PR).

Starting a new task from an opensource project (external contributor):

git reflow start opensource-user/opensource-project

1. Create fork if one doesn't already exist for the base repo
2. Create feature branch as usual
3. git reflow review would squash commits and then submit a cross-fork pull-request
4. git reflow deliver would check for merge of PR on base-repo, and then cleanup the local repo's feature branch as usual

Delivering (project member merging PR)

When merging down pull requests on opensource projects, it currently loses track of the original author since we're squash-merging the commits. We'll need some sort of way to retain the attribution to the original author (maybe using --author for the final commit?)

1. git reflow deliver external_contributor_username/project_name (doing this will perform the following)
2. git remote add remote_user_of_pull
3. git fetch remote_user_of_pull
4. git checkout master
5. git pull origin master
6. git merge --squash remote_user_of_pull/branch_of_pull
7. git commit --author "Author of PULL <[email protected]>"
8. git push origin master
9. Ask to cleanup remote and if Y: git remote rm remote_user_of_pull

We'll want to implement this as a Custom Workflow and added to the other workflows here.

details here: https://github.com/hone/mruby-cli

Hi,

What do you think about printing options from a git reflow --help ?

~/Code/dartdoc/test_package[sl-dual-nav] $ git reflow --help
No manual entry for git-reflow

Would it make sense for reflow not to require an lgtm from myself, if I've commented on the PR? Right now, I need to type lgtm into a comment on my PR before I can deliver a branch with reflow.

Just a note to create a document with instructions on how to contribute to GitReflow.

I'd like to assign a title/message from the command line for review.

Here's the syntax that seems immediately intuitive:

git reflow review -t "This is the title" -m "Here's a message"

I'm not using 2-factor auth.

After getting frustrated of all the 'Invalid username or password"' and some attempts of changing my password, I commented out rescue StandardError => e in git_reflow.rb to see what's wrong:

Please enter your GitHub username: steipete
Please enter your GitHub password (we do NOT store this): 
error: POST https://api.github.com/authorizations: 422 

My credentials must match, when I enter them wrongly I get

Please enter your GitHub username: steipete
Please enter your GitHub password (we do NOT store this): 
error: POST https://api.github.com/authorizations: 401 Bad credentials

GitHub says "Sending invalid fields will result in a 422 Unprocessable Entity response.".
What am I doing wrong here? Version 0.3.4 here (installed via gem install reflow)

Or better yet enable user to edit title on command line before creating PR during deliver. We have Slack notifications setup for PRs and having all these random PR titles pop up is confusing/annoying, especially for non-devs on the team who keep up with app progress.

Getting a 404 error when git reflow tries to do anything on a pull request. review fails, and even if I make a PR manually for the branch delver and status also fail.

Tried to re-run git reflow setup but it just tells me that

Your GitHub account was already setup with:   
    User Name:   
    Endpoint: https://api.github.com  

as does git reflow setup -l

Example of one of the errors (on review):
Error: #<Github::Error::NotFound: GET https://api.github.com/repos/github.com/sproutli/pulls?access_token=32162b54b3c8501f6b260e37b8a7f3d88cfc3d53%0A&base=master&head=github.com%3Aselectize&state=open: 404 Not Found>

My collaborator is getting the same error.

Workflows

Premise: Define your workflow in a config file that would plug-in to git-reflow. Like the way oh-my-zsh works with plugins combined with the idea of how Capistrano handles callbacks.

So you could define a file that has a bunch of before/after calls that can target the core workflow (the basic reflow commands) as well as target other workflows.

Core Workflow:

# Core workflow
commands :setup, :start, :review, :status, :stage, :deliver

start(branch_name) do
  run_command_with_label 'git pull origin', { GitReflow.current_branch }
  run_command_with_label 'git push origin', { "#{GitReflow.current_branch}:refs/heads/#{branch_name}" }
  run_command_with_label 'git checkout --track -b', { "#{branch_name} origin/#{branch_name}" }
end

# ... other commands would go after this

Customized Workflow

# would setup all default commands from above
require 'git_reflow/workflows/core' 

replace(:start) do
  # ... commands to run instead of git-reflow core
end

before(:start) do
  # ... do something else here
end

after(:start) do
  # ... do something else here
end

$ git reflow setup
Available remote Git Server services::

1. GitHub
2. BitBucket (team-owned repos only)
   Which service would you like to use for this project? 1
   Your GitHub account was already setup with:
   User Name:
   Endpoint: https://api.github.com

Let me know if you need more information.

I'd like to enforce that the reflow review process is followed by disallowing merging to master without reviews (unless the user forces it explicitly during an emergency).

Would this be a feature that could live in reflow?

I have my dotfiles in a public git repository. ~/.git/config is one of those files. In the current way of storing the OAuth token, I can't add the config line to the gitignore. What is the best way to make sure I never commit this?

I'd be happy to add something that can store the token in a different file, and maybe then put the file location in the git config? Is this something you'd merge in?

Currently if your origin points to an http url everything stops working.

Ideally, when I am presented the editor, this is what i'll see

rj_201_login_fix

this fixes 209 and should be good to go!

--end--

So, you're creating a PR? did you...

1. Write tests?
2. Add Documentation?
3. Merge in master?

Where, anything after --end-- is sourced from a file that the project defines. So, projects can use reflow and define their own checklist to display (or whatever else) in the editor, as you create the PR.

we then just split on --end-- and throw away anything after it, when creating the PR.

However, one snag is either we force a specific file name in the app root, or have to have some kind of project-level config to define it.

for "git reflow deliver branch_name" to work, I have to change
C:\Users\Administrator\Documents\GitHub\reponame.git\config
From
[remote "origin"]
url = https://username:[email protected]/accountowner/reponame.git
fetch = +refs/heads/:refs/remotes/origin/
To
[remote "origin"]
fetch = +refs/heads/:refs/remotes/origin/
url = [email protected]:accountowner/reponame.git

Is it known issue ?
otherwise it does not work.

When executing git reflow status I get

error: bad URI(is not URI?): https://api.github.com

commands which do not use GitHub API (eg. start) work as expected.

Any ideas? Thanks in advance.

Hi,

thanks for the helpful README! I was wondering if it could mention when I would want to install reflow or git_reflow ? Right now, it just says "or". :)

Thanks!

Don't know if it's a Ruby 2 / OSX Mavericks issue, but the setup fails with

git reflow setup
/Users/ea/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- json/pure (LoadError)
    from /Users/ea/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/ea/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/git_reflow-0.3.3/lib/git_reflow.rb:6:in `<top (required)>'
    from /Users/ea/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/ea/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/ea/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/git_reflow-0.3.3/bin/git-reflow:16:in `<top (required)>'
    from /Users/ea/.rbenv/versions/2.0.0-p247/bin/git-reflow:23:in `load'
    from /Users/ea/.rbenv/versions/2.0.0-p247/bin/git-reflow:23:in `<main>'

I couldn't find a way to use this against a github enterprise instance as it always attempts to connect to github.com / api.github.com

This is possible according to the documentation at http://peter-murach.github.io/github/

github = Github.new do |config|
  config.endpoint    = 'https://github.company.com/api/v3'
  config.site        = 'https://github.company.com'
end

As a policy, we ask developers to merge updates from the base branch (e.g. master) prior to submitting or resubmitting a PR for review. Due to merge squashing, it won't matter how many messy merge commits come, so this is good practice for a project where people are committing things that don't cause merge conflict but could still cause problems. A reflow command for this would be good.

~/Code/dartdoc/test_package[sl-remove-overlay-on-resize] $ git reflow deliver
git fetch origin master
From github.com:dart-lang/dartdoc
 * branch            master     -> FETCH_HEAD

git checkout sl-remove-overlay-on-resize
Already on 'sl-remove-overlay-on-resize'
Your branch is up-to-date with 'origin/sl-remove-overlay-on-resize'.
git pull origin sl-remove-overlay-on-resize
From github.com:dart-lang/dartdoc
 * branch            sl-remove-overlay-on-resize -> FETCH_HEAD
Already up-to-date.
git checkout sl-remove-overlay-on-resize
Already on 'sl-remove-overlay-on-resize'
Your branch is up-to-date with 'origin/sl-remove-overlay-on-resize'.
[deliver halted] You still need a LGTM from: devoncarew

Notice how devoncarew gave an lgtm.

Any ideas why reflow won't deliver the feature?

tmp_squash_msh seems to be hanging around if we use git reflow in other directories than root. This is due to this part of code.

    def append_to_squashed_commit_message(message = '')
      run "echo \"#{message}\" | cat - .git/SQUASH_MSG > ./tmp_squash_msg"
      run 'mv ./tmp_squash_msg .git/SQUASH_MSG'
    end

If we are not the the root directory, the relative ./git won't exist

We can change to something like:

    def append_to_squashed_commit_message(message = '')
     git_root_dir = `echo $(git rev-parse --show-toplevel)`
      run "echo \"#{message}\" | cat - #{git_root_dir}/.git/SQUASH_MSG > #{git_root_dir}/tmp_squash_msg"
      run 'mv #{git_root_dir}/tmp_squash_msg #{git_root_dir}/.git/SQUASH_MSG'
    end

Hi,

thanks for the helpful README! I was wondering if it could mention when I would want to install reflow or git_reflow ? Right now, it just says "or". :)

Thanks!

In my test repo with git_reflow (0.6.1) on osx 10.10.4:

marburg:git-review johan$ git reflow start testtest
From github.com:johanoskarsson/git-review
 * branch            master     -> FETCH_HEAD
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:johanoskarsson/git-review.git
 * [new branch]      master -> testtest
Switched to a new branch 'testtest'

<add some test commits>

marburg:git-review johan$  git reflow review
sh: /Users/johan/Dev/git-review/.git/GIT_REFLOW_PR_MSG: Permission denied

Review your PR:
--------
Title:
testtest

Body:

--------
Submit pull request? (Y)

git fetch origin master
From github.com:johanoskarsson/git-review
 * branch            master     -> FETCH_HEAD

git push origin testtest
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 295 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:johanoskarsson/git-review.git
   9271ae2..4fcfb32  testtest -> testtest


Error: #<NameError: wrong constant name >

http://take.ms/I1b8k

screenshot of error ☝️
alias grr - git reflow review

reflow successfully creates PR and assigns reviewer, however it does not open browser for review

Reflow depends on us having the ssh keys in place and using that as the authentication method for github. Not everyone will get their repo setup that way, so we need to cowardly refuse to work on a repo when they haven't used the ssh url

At the bottom of every PR, we can add the text "Created With Reflow" where reflow is a link to the project. Similar to "sent from my iphone"

This would need to be appended automatically; but for the most part appears at the bottom of the editor and can be easily nuked.

Perhaps a personal setting can decide to disable this feature for good, should the user be bothered by it.

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

There is even a License Finder to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for missing ones as a public service :)
https://gist.github.com/bf4/5952053#file-license_issue-rb-L13 So far it's going pretty well

Just installed git reflow with

gem install reflow

on OS X Mavericks with rbenv 0.4.0 and Ruby 2.1.0-p0 (also tried with 2.0.0-p353). I keep getting the following error:

~/code/project » git reflow                                                                                                                              
/usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/dsl.rb:203:in `verify_unused_in_option': f has already been specified as a switch in the command deliver (ArgumentError)
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/dsl.rb:197:in `block in verify_unused'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/dsl.rb:195:in `each'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/dsl.rb:195:in `verify_unused'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/dsl.rb:97:in `switch'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/command_support.rb:73:in `switch'
from /usr/local/Cellar/rbenv/0.4.0/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/git_reflow-0.3.4/lib/git_reflow/commands/deliver.rb:6:in `block in <top (required)>'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/dsl.rb:177:in `command'
from /usr/local/Cellar/rbenv/0.4.0/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/git_reflow-0.3.4/lib/git_reflow/commands/deliver.rb:4:in `<top (required)>'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:114:in `require'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:114:in `require'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/app.rb:280:in `block in load_commands'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/app.rb:277:in `each'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/app.rb:277:in `load_commands'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/app.rb:38:in `block in commands_from'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/app.rb:36:in `each'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/gli-2.8.1/lib/gli/app.rb:36:in `commands_from'
from /usr/local/opt/rbenv/versions/2.0.0-p353/lib/ruby/gems/2.0.0/gems/git_reflow-0.3.4/bin/git-reflow:24:in `<top (required)>'
from /usr/local/opt/rbenv/versions/2.0.0-p353/bin/git-reflow:23:in `load'
from /usr/local/opt/rbenv/versions/2.0.0-p353/bin/git-reflow:23:in `<main>'

I chased Google to find the answer, but got nothing. Any ideas?

P.S. This is probably something GLI-related?