Git Workflow Question: Getting Ready for a Pull Request

[John R. Graham]

I think this is a fairly normal workflow. I've done the following:

1. Check out "master".
   
2. Create a feature branch. Call it "feature".
   
3. Work on the feature branch, committing early an often with various temporary changes, debug chatter, and generally being very verbose about my reasoning, false starts, and so forth.
   
4. If other work is being done on master (not by me), merge and rebase as appropriate to keep my feature branch reasonably up to date with master.

Now I'm ready to submit my feature to upstream, but all of this commit chatter is meaningless to anyone but me. I also want to preserve the debug code, that I won't be submitting upstream, for my own benefit for future development on the feature branch. So what I want to do is:

1. Create a "release-candidate" branch from the current HEAD of the "feature" branch.
   
2. Edit out all of the extraneous debug chatter in the code and commit the clean code on the new branch with appropriate explanatory comments.
   
3. Do something so that the "release-candidate" branch is attached to the HEAD of master so that only the commits I want to be part of the pull request are in that branch.

It's that last step that I don't know how to do. Some pointers would be appreciated.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[logrusx]

[pingtoo]

[logrusx]

[pingtoo]

[keekkenen]

[John R. Graham]

Actually, I went for a mountain bike ride and, somewhere in the climb, I realized the answer. Here's the full recipe:

1. Check out "master" and create a "release-candidate" branch from the current HEAD of "master".
   
2. Create a patch from the diff of "master" and "feature".
   
3. Check out "release-candidate" and then apply the patch to the working directory.
   
4. Edit out all of the extraneous debug chatter in the code and commit the clean code on the "release-candidate" branch with appropriate explanatory comments.
   
5. QED

I was looking for a git command to do that directly, but on second thought, I don't need it.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hu]

Some users may want to locally commit their debug code, because constantly stashing and unstashing it around real code becomes a burden.

Maybe you are looking for git branch --set-upstream-to=branch?

I see a midair collision. There is a simple git flow for this.

• git checkout -b feature-clean origin/master
• git checkout -p feature-dirty -- ./
• Work through the prompts from git checkout -p to add hunks from feature-dirty into the working copy. Reject any that are debug-only.
• git commit

[John R. Graham]

Ah. Thank you! I'll work through that recipe.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[John R. Graham]