search

octopress / docs

Source for the octopress.org documentation website
24 stars 30 forks source link

setup: rbenv: add "rbenv local" #13

Closed super119 closed 10 years ago

super119 commented 10 years ago

Run "rbenv local 1.9.3-p0" before finishing the ruby installation. This makes sure the 1.9.3-p0 will be used during the Octopress installation.

Signed-off-by: Mark Zhang super119@139.com

super119 commented 10 years ago

I'm new to github. Is there a way to create patch versions? Say, I can create a v2/v3/v4... for this patch so that we don't need to abandon a pull request and create a new one just for some minor changes?

parkr commented 10 years ago

Yeah! So this PR is going to have to be abandoned unfortunately, because you used the master (main) branch. Here are the basic instructions for submitting a patch:

  1. Fork the repo
  2. Create a new branch. Name it appropriately in order to describe what "feature" or "fix" it introduces. (e.g. git checkout -b my-branch-name)
  3. Commit your changes to this branch (git add path/to/files/I/edited.extname; git commit -m "Description of the changes I made")
  4. Push up your changes to your fork
  5. Create a pull request from your_username:my-branch-name back to owners_username:master
  6. As modifications to the PR need to be made, add new commits and push them to your feature branch

Key principles:

  1. Every PR has its own branch
  2. Every commit of your own on your feature branch will be included in the PR, even ones made later, after submission
super119 commented 10 years ago

Thanks for the info, parkr. I just have 1 question: if we create new commits on feature branch, do we need to do some rebase/squash works when we agree on the PR? For example, we create 3 versions of the patch on feature branch:

commit v3 commit v2 commit v1

but you know commit v2 is based on v1 and also commit v3 is based on v2. So if we accept the PR, commit v1/v2/v3 will all be merged into mainline, which is not what we want. So I guess maybe we need to do a git rebase to squash them?

In addition, if the change has multiple of commits, the thing becomes more complex...

So I think maybe we can always put the latest patch on feature branch, with a version tag like: [PATCH v2] at the beginning of commit message, then we can use "git push -f" to force update on feature branch every time. When there is an agreement on patch, you can just merge the commit directly.

parkr commented 10 years ago

Squashing is only necessary if your three commits change the same things and you don't want that history. If the history is valuable or if the individual commits pertain to different changes altogether (but part of one larger feature set/enhancement in the PR) then leave them separate.

parkr commented 10 years ago

Ideally, one proposal will be in one PR. If you have another version that you're considering, discuss it rather than posting multiple PRs.

super119 commented 10 years ago

Yes, sometimes we don't need the history. Just like the patch I filed, actually I submitted 3 versions of the patch which target a same proposal. So what we want is the final version, we have to squash the 3 version patches before the codes get merged.

super119 commented 10 years ago

What I want to say is, one proposal may includes multiple commits. At that time we file a patch set while not a single patch, right? So if we still keep publishing commits on feature branch according to the discussion, when the discussion is done, we need to go back and create a final version patch set which can be used for merging.

So in short, in spite of publishing commits is good for saving history, it will be better to just push the latest patch(or patch set) on feature branch.

But you know, this is not a big deal, just my 2 cents. I can live with that if you insist on keeping the patch history.