Please don't rebase or amend the master branch

[jwhitley]

Hi Roy,

I find that I regularly get merge problems on master when pulling into unmodified clones of this repository. It appears that this repository's master branch is regularly being rebased, or is otherwise subjected to git history modification such as via git commit --amend. Please don't modify the master branch's history; it's very problematic for anyone who tracks your repository. In my case, I've added rbenv-bundler to the repos being installed and updated by rbenv-installer as part of an automated workflow. This continually breaks with explicit merges and/or conflicts being reported for what should be fast-forward merges.

Pro Git has a nice explanation of the problems introduced by rebasing public branches. This explanation applies to all forms of git history modification, including amend.

For example, a clone made around July 26th shows this history:

* 130934f  (8 days)     <Roy Liu>         (HEAD, 0.94, master) Make minor organizational changes
* cb0d4a2  (9 days)     <Roy Liu>         Update the RbenvBundler#ensure_capable_ruby method so that it no longer claims JRuby 1.9.x as capable when it's not (lack of Kernel.fork)
* 235d5a3  (11 days)    <Roy Liu>         Update the README
* d419591  (11 days)    <Roy Liu>         Fix code related to the corner cases when either the manifest.txt file doesn't exist or the ruby_profiles.yml file is first created
* 41fd6ea  (11 days)    <Roy Liu>         Improve error handling for forked child processes
* dea9cde  (13 days)    <Roy Liu>         Add the .yardopts file
* 3aac2e5  (3 weeks)    <Roy Liu>         Make minor organizational changes
* a0c3d8b  (8 weeks)    <Roy Liu>         (0.93) Check the recency of the ~/.rbenv/versions directory instead of rbenv Ruby directories to determine if Rubies have been added or removed.

Compare that to a clone made as of this writing (July 31st):

* 970bfef  (8 days)     <Roy Liu>         (HEAD, 0.94, origin/master, origin/HEAD, master) Make minor organizational changes
* cb0d4a2  (9 days)     <Roy Liu>         Update the RbenvBundler#ensure_capable_ruby method so that it no longer claims JRuby 1.9.x as capable when it's not (lack of Kernel.fork)
* 235d5a3  (11 days)    <Roy Liu>         Update the README
* d419591  (11 days)    <Roy Liu>         Fix code related to the corner cases when either the manifest.txt file doesn't exist or the ruby_profiles.yml file is first created
* 41fd6ea  (11 days)    <Roy Liu>         Improve error handling for forked child processes
* dea9cde  (13 days)    <Roy Liu>         Add the .yardopts file
* 3aac2e5  (3 weeks)    <Roy Liu>         Make minor organizational changes
* a0c3d8b  (8 weeks)    <Roy Liu>         (0.93) Check the recency of the ~/.rbenv/versions directory instead of rbenv Ruby directories to determine if Rubies have been added or removed.

The commit id for the most recent commit has changed; the two histories have diverged and are no longer cleanly mergable.

FWIW, what I do on my public repos is to follow a simple GitHub Flow style of work:

1. Interim work goes on a descriptively named local branch
2. When that stabilizes a bit, I'll rebase to clean up the history then push it to GitHub.
3. I use hub to create a pull request (git pull-request) from that branch.
4. I'll merge that work via GitHub's Pull Request UI.

This lets me play around quite a lot on the branches, including rebasing, amending, etc. without disturbing master's history. Sometimes I'll even let a branch or pull request sit for a bit while I think about it.. sometimes I'll throw it away without merging. Then no one tracking master had to worry about that little hiccup...

[carsomyr]

@jwhitley Point taken about the automated workflow. I got the impression that most people used the plugin purely for development purposes, and so a little amending wouldn't ruin anyone's day. Out of curiosity, what type of environment is rbenv-bundler included in?

[jwhitley]

Thanks for understanding!

To your question, we're using rbenv-installer to setup rbenv with ruby-build, rbenv-vars, and rbenv-bundler as part of the host-side ruby environment for an automated Vagrant VM setup. There's a top-level toolbox script with an "install/update the universe" command that uses rbenv-installer to update the rbenv plugins, which is where things break down. In this case, the developers using this environment aren't necessarily directly using rbenv at all. The aforementioned top-level toolbox script loads and manages the rbenv environment, so rbenv itself is "under the hood" unless a dev chooses to load it in their rcfiles.

Likewise, I'm already thinking about using this same strategy for maintaining rbenv + bundler inside of a Vagrant VM environment (or other Chef-driven env).

[carsomyr]

Well, I guess rbenv-bundler grew up and the master branch is no longer my "anything goes" playground. The automated pulls underline that fact. FYI, you can still pull from rewritten history: Just add --rebase.