8

So here's a typical workflow on Github...

  1. Like some project -> fork it -> git clone https://github.com/you/someproject.

  2. Open project. Like what you see, but make some changes.

  3. Having been careful to work only in a feature-branch (git checkout -b some-feature), you decide to make a pull request with the upstream maintainer - after having pushed your feature-branch to your Github fork.

  4. Maintainer, for whatever reason, declines the pull.

For example.. here is a failed pull request that I submitted that matches the above scenario...

Now typically, if the maintainer HAD merged the pull... the workflow would be simple... On my local machine, I would commit any local changes on whatever feature-branch I was on at the time... git fetch --all, git checkout master, git pull upstream --ff-only. Then replay my changes on top of that, as desired...

BUT...

What if I decide that you want to continue working off the changes to my fork, regrdless... yet still want to be able to track + merge changes that happen upstream? Ordinarily, I would delete the feature branch, and go on my way.. How can you maintain a master branch that is able to be merged upstream, yet maintains your fork's features while being "permanently detached" from upstream's HEAD?

Improve this question
4
  • 11
    Gratuitous changes to formatting are not going to be accepted to any single project I've ever heard of and if you insist on keeping them in your repository, welcome to your little personal well deserved merging hell. If you just cleaned up warnings, most probably it would be accepted, though you might still be asked to send it split to reasonably sized chunks. Even changes to make formatting self-consistent might be accepted. But changes that change formatting to different one never are. Because everybody else is used to the current formatting and because it will cause problems with merging.
    – Jan Hudec
    Oct 16, 2013 at 15:24
  • Just for context, the diff stats of the pull request is: "Showing 15 changed files with 832 additions and 1,478 deletions"
    – user40980
    Oct 16, 2013 at 15:51
  • 2
    @Jan Hudec My question is about how to use the tools... NOT if you like my pull request, lol. Personally, I can't deal with a HUGE license (on an OSS project) at the top of every F-ing file, hence the large number of deletions.. and the other changes were conventional and did nothing but remove compiler warnings and make the code actually readable. Regardless, this question is about how one can "work different", without being told what is "right" and "wrong".
    – alex gray
    Oct 16, 2013 at 16:12
  • 1
    @alexgray: That's why I am not writing it as answer, but as comment.
    – Jan Hudec
    Oct 16, 2013 at 19:46

1 Answer 1

Reset to default
6

Regardless of the use of your scenario, here is how you can do it:

  • master is exactly of the version the upstream master has
  • custom is your own "master" branch in which you have applied the formatting changes
  • all feature branches are branched off custom if you don't want them to be pulled into upstream master
  • Once master is updated, you rebase custom to master and then you rebase your feature branches to custom

With this strategy it should work. But keep in mind that every change you make in a feature branch based upon custom won't be accepted into upstream master.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.