Maintaining a fork with patches in master
up vote
1
down vote
favorite
I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.
What I want to achieve:
- The GitHub page of the fork should point to the patched version of the project instead of the original one.
- I should be able to easily merge new upstream code while preserving a separate history for my own commits.
My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.
Questions:
- Is there an easier or cleaner way to achieve the same results?
- Should I fork via GitHub web-interface and then move
master, or should I create the repository locally as described in this answer?
git github git-fork
asked Nov 12 at 0:05
M.Marcello
84
add a comment |
up vote
1
down vote
favorite
I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.
What I want to achieve:
- The GitHub page of the fork should point to the patched version of the project instead of the original one.
- I should be able to easily merge new upstream code while preserving a separate history for my own commits.
My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.
Questions:
- Is there an easier or cleaner way to achieve the same results?
- Should I fork via GitHub web-interface and then move
master, or should I create the repository locally as described in this answer?
git github git-fork
asked Nov 12 at 0:05
M.Marcello
84
This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.
What I want to achieve:
- The GitHub page of the fork should point to the patched version of the project instead of the original one.
- I should be able to easily merge new upstream code while preserving a separate history for my own commits.
My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.
Questions:
- Is there an easier or cleaner way to achieve the same results?
- Should I fork via GitHub web-interface and then move
master, or should I create the repository locally as described in this answer?
git github git-fork
asked Nov 12 at 0:05
M.Marcello
84
I want to maintain a fork with custom functionality added on top of the original code. It is not a contribution to the project itself and won't be merged upstream.
What I want to achieve:
- The GitHub page of the fork should point to the patched version of the project instead of the original one.
- I should be able to easily merge new upstream code while preserving a separate history for my own commits.
My current plan is to have the upstream/master branch in the fork repository as vendor, from which my own master will be branched. Whenever there is a stable release upstream I can pull & push it into the vendor branch and than rebase my master.
Questions:
- Is there an easier or cleaner way to achieve the same results?
- Should I fork via GitHub web-interface and then move
master, or should I create the repository locally as described in this answer?
git github git-fork
git github git-fork
asked Nov 12 at 0:05
M.Marcello
84
asked Nov 12 at 0:05
M.Marcello
84
edited Nov 12 at 9:32
asked Nov 12 at 0:05
M.Marcello
84
asked Nov 12 at 0:05
M.Marcello
84
asked Nov 12 at 0:05
M.Marcello
84
84
This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14
add a comment |
This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14
This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14
This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
A fork is just a more formal way to link those two GitHub repo.
You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.
git fetch upstream
git checkout master
git rebase upstream/master
answered Nov 12 at 5:40
VonC
826k28525983137
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53254484%2fmaintaining-a-fork-with-patches-in-master%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
A fork is just a more formal way to link those two GitHub repo.
You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.
git fetch upstream
git checkout master
git rebase upstream/master
answered Nov 12 at 5:40
VonC
826k28525983137
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
add a comment |
up vote
0
down vote
accepted
A fork is just a more formal way to link those two GitHub repo.
You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.
git fetch upstream
git checkout master
git rebase upstream/master
answered Nov 12 at 5:40
VonC
826k28525983137
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
A fork is just a more formal way to link those two GitHub repo.
You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.
git fetch upstream
git checkout master
git rebase upstream/master
answered Nov 12 at 5:40
VonC
826k28525983137
A fork is just a more formal way to link those two GitHub repo.
You don't even need to name upstream/master as "vendor": you can directly rebase your own master branch on top of that remote branch.
git fetch upstream
git checkout master
git rebase upstream/master
answered Nov 12 at 5:40
VonC
826k28525983137
answered Nov 12 at 5:40
VonC
826k28525983137
answered Nov 12 at 5:40
VonC
826k28525983137
answered Nov 12 at 5:40
VonC
826k28525983137
826k28525983137
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
add a comment |
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
That's an interesting approach. I guess I should've paid more attention to the git-rebase manpages. Thanks!
– M.Marcello
Nov 12 at 9:40
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53254484%2fmaintaining-a-fork-with-patches-in-master%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This seems like a perfectly reasonable workflow. Forking via the GitHub web interface is nice because it provides a pointer to the original project.
– larsks
Nov 12 at 4:14