Re: [git-users] Adding a pull request (newer master) to my build
On 2017-08-12, at 12:50 AM, Philip Oakley <philipoak...@iee.org> wrote: > Michael, > > If that master and the PR979 branches have been merged and both tips are now > ahead of the merge point, then git itself has no way of deciding which side > of the merge is which. [you hadn't labelled your diagram] That is, git > doesn't keep a note of which side would have been the first and second > parent line. However, you should know ;-), so at that point in time you > would need to give a true indication of a commit that is in the PR979 line, > but not on the master line to get the merge base. > > I suspect part of the problem is the multiplicity of the "masters" from the > different remotes. I expect that when you qualify which the remote it is > that has the merge base that things will improve. > > The other part is whether the PR was merged into their master (on the > remote), or master merged into the PR. That is, after the merge on the > remote, does the PR still point to the tip of the original patch series, or > has it progressed into, or even past, their merge, as you don't want the > contents of their merge in your tree. > > Philip remotes/origin/Pr979 points to the tip of the branch (a whopping one commit long branch). It was merged into master (not the other way around). But yea, rebase's man page even says that if something was merged into the upstream it won't stay around for later. ... Rebase is *still* confusing me. Normally, if I understand things, it wants to change where the source label points at (so you wind up garbage collecting the version of the branch you no longer want), and moves the label to the new set of commits. But this time it did not do that. It did, however, leave me in detached head state after success. > > - Original Message - From: "Michael" <keybou...@gmail.com> > To: <git-users@googlegroups.com> > Sent: Thursday, August 10, 2017 3:55 PM > Subject: Re: [git-users] Adding a pull request (newer master) to my build > > > > On 2017-08-09, at 12:28 PM, Philip Oakley <philipoak...@iee.org> wrote: > >> Hi Michael, >> >> [don't abuse the fact that 'head' on windows will find the HEAD pseudoref >> file, as there are a few cases where it fails - there's been mention >> recently on the Git List in the last week or so] >> >> You didn't say what messages you got from the rebase command - did it say >> how many patches it was going to rebase? >> The command looks sensible > > I'm sorry, I thought I did. > >> keybounceMBP:obs-studio michael$ git checkout -b Pull979 >> Switched to a new branch 'Pull979' >> keybounceMBP:obs-studio michael$ git rebase --onto head origin/master >> origin/pr/979 >> First, rewinding head to replay your work on top of it... >> keybounceMBP:obs-studio michael$ >> >> Nope, it did not apply anything to my current head. Help? > > No patches applied. > > Adding the "-i" flag? > noop > > # Rebase 91c292d3..086e9cf0 onto 4684294b (1 command) > > Now, this does tell me which commits it wants to use. > ... Aha! This is not "When Pr 979 forked off master .. tip of pr 979" -- > i.e., all commits reachable from the pull request and not master. This is > "tip of master .. tip of pr979" -- which is almost the same. > > Except that pr979 has been merged into the new master. > > In other words, my graph looks like (hand drawn) > | > |\ > | \ > | | > | | > | / > |/ > | > > And it's that side loop that I want to make a copy of. > > What's the way in git to specify the point where one branch forked off > another -- i.e, when that "checkout -b" command was run? I'm guessing it > would be the first time that the parent of pr979 matches the "first parent" > chain of master? I have no idea how to specify that in git. > > But ... the sibling on master (the other side of the merge into master) is > 5f3cd, and > > keybounceMBP:obs-studio michael$ git checkout Pull979 > Switched to branch 'Pull979' > keybounceMBP:obs-studio michael$ git rebase --onto head 5f3cd origin/pr/979 > First, rewinding head to replay your work on top of it... > Applying: UI: Fix settings window minimum width/height > keybounceMBP:obs-studio michael$ gitk > ^C > keybounceMBP:obs-studio michael$ > > Yes, that does it. > > So, maybe an easier way to ask that "how do I specify this range": What's an > easy way to ask git for the siblings of a given commit (if commit X is > followed by a merge commit, the other parent of that merge)? > > Also, is there a simpler way to specify that rebase command? "$ gi
Re: [git-users] Adding a pull request (newer master) to my build
Michael, If that master and the PR979 branches have been merged and both tips are now ahead of the merge point, then git itself has no way of deciding which side of the merge is which. [you hadn't labelled your diagram] That is, git doesn't keep a note of which side would have been the first and second parent line. However, you should know ;-), so at that point in time you would need to give a true indication of a commit that is in the PR979 line, but not on the master line to get the merge base. I suspect part of the problem is the multiplicity of the "masters" from the different remotes. I expect that when you qualify which the remote it is that has the merge base that things will improve. The other part is whether the PR was merged into their master (on the remote), or master merged into the PR. That is, after the merge on the remote, does the PR still point to the tip of the original patch series, or has it progressed into, or even past, their merge, as you don't want the contents of their merge in your tree. Philip - Original Message - From: "Michael" <keybou...@gmail.com> To: <git-users@googlegroups.com> Sent: Thursday, August 10, 2017 3:55 PM Subject: Re: [git-users] Adding a pull request (newer master) to my build On 2017-08-09, at 12:28 PM, Philip Oakley <philipoak...@iee.org> wrote: Hi Michael, [don't abuse the fact that 'head' on windows will find the HEAD pseudoref file, as there are a few cases where it fails - there's been mention recently on the Git List in the last week or so] You didn't say what messages you got from the rebase command - did it say how many patches it was going to rebase? The command looks sensible I'm sorry, I thought I did. keybounceMBP:obs-studio michael$ git checkout -b Pull979 Switched to a new branch 'Pull979' keybounceMBP:obs-studio michael$ git rebase --onto head origin/master origin/pr/979 First, rewinding head to replay your work on top of it... keybounceMBP:obs-studio michael$ Nope, it did not apply anything to my current head. Help? No patches applied. Adding the "-i" flag? noop # Rebase 91c292d3..086e9cf0 onto 4684294b (1 command) Now, this does tell me which commits it wants to use. ... Aha! This is not "When Pr 979 forked off master .. tip of pr 979" -- i.e., all commits reachable from the pull request and not master. This is "tip of master .. tip of pr979" -- which is almost the same. Except that pr979 has been merged into the new master. In other words, my graph looks like (hand drawn) | |\ | \ | | | | | / |/ | And it's that side loop that I want to make a copy of. What's the way in git to specify the point where one branch forked off another -- i.e, when that "checkout -b" command was run? I'm guessing it would be the first time that the parent of pr979 matches the "first parent" chain of master? I have no idea how to specify that in git. But ... the sibling on master (the other side of the merge into master) is 5f3cd, and keybounceMBP:obs-studio michael$ git checkout Pull979 Switched to branch 'Pull979' keybounceMBP:obs-studio michael$ git rebase --onto head 5f3cd origin/pr/979 First, rewinding head to replay your work on top of it... Applying: UI: Fix settings window minimum width/height keybounceMBP:obs-studio michael$ gitk ^C keybounceMBP:obs-studio michael$ Yes, that does it. So, maybe an easier way to ask that "how do I specify this range": What's an easy way to ask git for the siblings of a given commit (if commit X is followed by a merge commit, the other parent of that merge)? Also, is there a simpler way to specify that rebase command? "$ git rebase --onto head 5f3cd origin/pr/979" just looks like it has a simpler way to state it -- would "git rebase 5f3cd..origin/pr/979" be the same? If is not specified, the upstream configured in branch..remote and branch..merge options will be used (see git-config(1) for details) and the --fork-point option is assumed. If you are currently not on any branch or if the current branch does not have a configured upstream, the rebase will abort. ... I still do not understand this paragraph. This did not come from the markov generator? :-) Try the invocation with the -i option to find out what the instruction list (the patch list) looks like - I normally do. In fact (IIUC) the patches are all hidden in the .git directory, so you you can see if they have what you expect. Philip - Original Message - From: "Michael" <keybou...@gmail.com> To: <git-users@googlegroups.com> Sent: Wednesday, August 09, 2017 12:53 AM Subject: Re: [git-users] Adding a pull request (newer master) to my build Thank you! And yes, everything in this case has a common root at tag 18.0.2. So, if I'm understanding this correctly, what I want is git checkout LocalMaster git checkout -b Pull979 git rebase --onto head origin/master
Re: [git-users] Adding a pull request (newer master) to my build
On 2017-08-09, at 12:28 PM, Philip Oakley <philipoak...@iee.org> wrote: > Hi Michael, > > [don't abuse the fact that 'head' on windows will find the HEAD pseudoref > file, as there are a few cases where it fails - there's been mention recently > on the Git List in the last week or so] > > You didn't say what messages you got from the rebase command - did it say how > many patches it was going to rebase? > The command looks sensible I'm sorry, I thought I did. > keybounceMBP:obs-studio michael$ git checkout -b Pull979 > Switched to a new branch 'Pull979' > keybounceMBP:obs-studio michael$ git rebase --onto head origin/master > origin/pr/979 > First, rewinding head to replay your work on top of it... > keybounceMBP:obs-studio michael$ > > Nope, it did not apply anything to my current head. Help? No patches applied. Adding the "-i" flag? noop # Rebase 91c292d3..086e9cf0 onto 4684294b (1 command) Now, this does tell me which commits it wants to use. ... Aha! This is not "When Pr 979 forked off master .. tip of pr 979" -- i.e., all commits reachable from the pull request and not master. This is "tip of master .. tip of pr979" -- which is almost the same. Except that pr979 has been merged into the new master. In other words, my graph looks like (hand drawn) | |\ | \ | | | | | / |/ | And it's that side loop that I want to make a copy of. What's the way in git to specify the point where one branch forked off another -- i.e, when that "checkout -b" command was run? I'm guessing it would be the first time that the parent of pr979 matches the "first parent" chain of master? I have no idea how to specify that in git. But ... the sibling on master (the other side of the merge into master) is 5f3cd, and keybounceMBP:obs-studio michael$ git checkout Pull979 Switched to branch 'Pull979' keybounceMBP:obs-studio michael$ git rebase --onto head 5f3cd origin/pr/979 First, rewinding head to replay your work on top of it... Applying: UI: Fix settings window minimum width/height keybounceMBP:obs-studio michael$ gitk ^C keybounceMBP:obs-studio michael$ Yes, that does it. So, maybe an easier way to ask that "how do I specify this range": What's an easy way to ask git for the siblings of a given commit (if commit X is followed by a merge commit, the other parent of that merge)? Also, is there a simpler way to specify that rebase command? "$ git rebase --onto head 5f3cd origin/pr/979" just looks like it has a simpler way to state it -- would "git rebase 5f3cd..origin/pr/979" be the same? If is not specified, the upstream configured in branch..remote and branch..merge options will be used (see git-config(1) for details) and the --fork-point option is assumed. If you are currently not on any branch or if the current branch does not have a configured upstream, the rebase will abort. ... I still do not understand this paragraph. This did not come from the markov generator? :-) > > Try the invocation with the -i option to find out what the instruction list > (the patch list) looks like - I normally do. > > In fact (IIUC) the patches are all hidden in the .git directory, so you you > can see if they have what you expect. > > Philip > > - Original Message - From: "Michael" <keybou...@gmail.com> > To: <git-users@googlegroups.com> > Sent: Wednesday, August 09, 2017 12:53 AM > Subject: Re: [git-users] Adding a pull request (newer master) to my build > > > Thank you! And yes, everything in this case has a common root at tag 18.0.2. > > So, if I'm understanding this correctly, what I want is > > git checkout LocalMaster > git checkout -b Pull979 > git rebase --onto head origin/master origin/pr/979 > > ... Does that make sense to you? > > keybounceMBP:obs-studio michael$ git checkout -b Pull979 > Switched to a new branch 'Pull979' > keybounceMBP:obs-studio michael$ git rebase --onto head origin/master > origin/pr/979 > First, rewinding head to replay your work on top of it... > keybounceMBP:obs-studio michael$ > > Nope, it did not apply anything to my current head. Help? > > On 2017-08-08, at 3:54 PM, Philip Oakley <philipoak...@iee.org> wrote: > >> Hi Michael, >> >> I almost always end up using the three parameter version of rebase! for that >> version you provide the start point and the end point (of the original >> series to be rebased) and a --onto reference. That way I can be certain that >> I got just the right parts being transcribed as a patch series. >> >> I also usuall create myself a second branch name for the original series >> (e.g. series1) so that I can easily go back to it. >> >> from my notelet text file: &g
Re: [git-users] Adding a pull request (newer master) to my build
Hi Michael, [don't abuse the fact that 'head' on windows will find the HEAD pseudoref file, as there are a few cases where it fails - there's been mention recently on the Git List in the last week or so] You didn't say what messages you got from the rebase command - did it say how many patches it was going to rebase? The command looks sensible Try the invocation with the -i option to find out what the instruction list (the patch list) looks like - I normally do. In fact (IIUC) the patches are all hidden in the .git directory, so you you can see if they have what you expect. Philip - Original Message - From: "Michael" <keybou...@gmail.com> To: <git-users@googlegroups.com> Sent: Wednesday, August 09, 2017 12:53 AM Subject: Re: [git-users] Adding a pull request (newer master) to my build Thank you! And yes, everything in this case has a common root at tag 18.0.2. So, if I'm understanding this correctly, what I want is git checkout LocalMaster git checkout -b Pull979 git rebase --onto head origin/master origin/pr/979 ... Does that make sense to you? keybounceMBP:obs-studio michael$ git checkout -b Pull979 Switched to a new branch 'Pull979' keybounceMBP:obs-studio michael$ git rebase --onto head origin/master origin/pr/979 First, rewinding head to replay your work on top of it... keybounceMBP:obs-studio michael$ Nope, it did not apply anything to my current head. Help? On 2017-08-08, at 3:54 PM, Philip Oakley <philipoak...@iee.org> wrote: Hi Michael, I almost always end up using the three parameter version of rebase! for that version you provide the start point and the end point (of the original series to be rebased) and a --onto reference. That way I can be certain that I got just the right parts being transcribed as a patch series. I also usuall create myself a second branch name for the original series (e.g. series1) so that I can easily go back to it. from my notelet text file: Three parameter rebase to move a sequence of commits git rebase --onto master next topic git rebase --onto where is either: the <> or ^ (i.e. parent of) if is omited, then HEAD is assumed. Interactive git rebase -i -- Philip PS I am presuming that all these different forks do have a common root commit, as they were ultimately forks of a common source, not that this matters for the 3 parameter version of rebase! - Original Message - From: "Michael" <keybou...@gmail.com> Sent: Tuesday, August 08, 2017 9:43 PM On 2017-08-08, at 1:27 PM, Philip Oakley <philipoak...@iee.org> wrote: Hi Michael, sounds like you need (one way of viewing the steps required) to rebase the old series "take the total deltas " and apply that to a new branch taken from 'current branch (LocalMaster)'. This (rebase) will give you a clean copy of the series as patches (it is what rebase does beneath the covers), and add them to the new branch. (it depends on how you want to retain the old branch position - see later) Yea, this morning I had the idea that rebase would do it, but I don't know what arguments to use. Rebase, as I understand it, normally takes something that has a common parent, and takes everything from that common parent to the present and moves it to where you are now. What I am working with basically does not have a common parent. And I don't know how to tell that to rebase. Nor do I know how, or even if, it can track future updates to said remote branch. An example of that last one. Lets say I have a fork of youtube-dl. I have fetch targets (repositories, fetch lines) for things such as pull requests in the official repository, and updates people have made in other cloned repositories that are not currently pul requests. I can do something like git fetch git fetch johnhawk git fetch gkoelln and, if any of them updated, I could then do git checkout new git merge Disney git merge Dish to update the support for Dish and some Disney websites -- because those are remote branches that update as the other people update their public repositories. This works because I'm willing to advance master on youtube-dl (side note: I'm pulling in three remote branches and one unmerged pull request. This is not just a "what-if"). But what if I was not willing to (such as this case with OBS)? Right now, the change in pr 979 is tiny. I could just recreate it, instead of rebasing it. But what if it were not so trivial, and more, what if it were still being developed? What would be the way to automatically fetch, rebase, and merge, in the same way that you can fetch and merge branches now? (And what the heck do I say to rebase to get it to take only a portion of what happened since the last common parent, since everything since the last common parent is a no-go for me?) Once you have that rebased series in the new branch, you can merge it in (--no-ff) with a message about
Re: [git-users] Adding a pull request (newer master) to my build
so as not to loose >> your original series, before doing the rebase, and then add the second merge >> of the --no-ff rebased history. >> >> In the latter case the --first parent log should read ~~: >> abc123 merge: rebased pr/897 series >> def456 merge: original pr/987 series, pinned as second parent, using --OURS. >> 78code former tip commit: whatever... >> >> Exactly how to do any fixup during the rebase is another story ;-) >> >> >> That would be my thoughts about retaining the old as well as the new. >> >> Hope it works for you.. >> >> Philip >> >> - Original Message - From: "Michael" <keybou...@gmail.com> >> To: <git-users@googlegroups.com> >> Sent: Tuesday, August 08, 2017 3:39 AM >> Subject: [git-users] Adding a pull request (newer master) to my build >> >> >> I'm looking for how to add a pull request, based off a newer master, to my >> master. >> >> The specifics: I'm trying to work with OBS 18.0.2 (version 19 won't run on >> my older OS). I'm trying to add in a pull request (979, >> https://github.com/jp9000/obs-studio/pull/979 ) to my build. >> >> That pull request is based on a nearly current master, so "git merge " tries >> to bring in all of master. >> >> I've done this with other github stuff. I've got a version of youtube-dl, >> for example, that includes a few prosposed pull requests. Those don't give >> me trouble, because I keep updating master, and those pull requests don't >> add anything that gives me trouble. >> >> This one? What I want seems pretty simple. I want to take the total deltas >> of this (origin/pr/979) since it left origin/master, and apply that to the >> current branch (LocalMaster). >> >> How to do that, and keep it updated if that pull request is updated, is what >> I don't know how. In this case, it's unlikely to be updated, as it's already >> merged into the newest master. But in general, if I'm assembling a >> "frankenstein's monster" from pieces, how do I glue the pieces together? >> >> --- >> Entertaining minecraft videos >> http://YouTube.com/keybounce >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > --- > Entertaining minecraft videos > http://YouTube.com/keybounce > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Adding a pull request (newer master) to my build
so as not to loose >> your original series, before doing the rebase, and then add the second merge >> of the --no-ff rebased history. >> >> In the latter case the --first parent log should read ~~: >> abc123 merge: rebased pr/897 series >> def456 merge: original pr/987 series, pinned as second parent, using --OURS. >> 78code former tip commit: whatever... >> >> Exactly how to do any fixup during the rebase is another story ;-) >> >> >> That would be my thoughts about retaining the old as well as the new. >> >> Hope it works for you.. >> >> Philip >> >> - Original Message - From: "Michael" <keybou...@gmail.com> >> To: <git-users@googlegroups.com> >> Sent: Tuesday, August 08, 2017 3:39 AM >> Subject: [git-users] Adding a pull request (newer master) to my build >> >> >> I'm looking for how to add a pull request, based off a newer master, to my >> master. >> >> The specifics: I'm trying to work with OBS 18.0.2 (version 19 won't run on >> my older OS). I'm trying to add in a pull request (979, >> https://github.com/jp9000/obs-studio/pull/979 ) to my build. >> >> That pull request is based on a nearly current master, so "git merge " tries >> to bring in all of master. >> >> I've done this with other github stuff. I've got a version of youtube-dl, >> for example, that includes a few prosposed pull requests. Those don't give >> me trouble, because I keep updating master, and those pull requests don't >> add anything that gives me trouble. >> >> This one? What I want seems pretty simple. I want to take the total deltas >> of this (origin/pr/979) since it left origin/master, and apply that to the >> current branch (LocalMaster). >> >> How to do that, and keep it updated if that pull request is updated, is what >> I don't know how. In this case, it's unlikely to be updated, as it's already >> merged into the newest master. But in general, if I'm assembling a >> "frankenstein's monster" from pieces, how do I glue the pieces together? >> >> --- >> Entertaining minecraft videos >> http://YouTube.com/keybounce >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > --- > Entertaining minecraft videos > http://YouTube.com/keybounce > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Adding a pull request (newer master) to my build
Hi Michael, I almost always end up using the three parameter version of rebase! for that version you provide the start point and the end point (of the original series to be rebased) and a --onto reference. That way I can be certain that I got just the right parts being transcribed as a patch series. I also usuall create myself a second branch name for the original series (e.g. series1) so that I can easily go back to it. from my notelet text file: Three parameter rebase to move a sequence of commits git rebase --onto master next topic git rebase --onto where is either: the <> or ^ (i.e. parent of) if is omited, then HEAD is assumed. Interactive git rebase -i -- Philip PS I am presuming that all these different forks do have a common root commit, as they were ultimately forks of a common source, not that this matters for the 3 parameter version of rebase! - Original Message - From: "Michael" <keybou...@gmail.com> Sent: Tuesday, August 08, 2017 9:43 PM On 2017-08-08, at 1:27 PM, Philip Oakley <philipoak...@iee.org> wrote: Hi Michael, sounds like you need (one way of viewing the steps required) to rebase the old series "take the total deltas " and apply that to a new branch taken from 'current branch (LocalMaster)'. This (rebase) will give you a clean copy of the series as patches (it is what rebase does beneath the covers), and add them to the new branch. (it depends on how you want to retain the old branch position - see later) Yea, this morning I had the idea that rebase would do it, but I don't know what arguments to use. Rebase, as I understand it, normally takes something that has a common parent, and takes everything from that common parent to the present and moves it to where you are now. What I am working with basically does not have a common parent. And I don't know how to tell that to rebase. Nor do I know how, or even if, it can track future updates to said remote branch. An example of that last one. Lets say I have a fork of youtube-dl. I have fetch targets (repositories, fetch lines) for things such as pull requests in the official repository, and updates people have made in other cloned repositories that are not currently pul requests. I can do something like git fetch git fetch johnhawk git fetch gkoelln and, if any of them updated, I could then do git checkout new git merge Disney git merge Dish to update the support for Dish and some Disney websites -- because those are remote branches that update as the other people update their public repositories. This works because I'm willing to advance master on youtube-dl (side note: I'm pulling in three remote branches and one unmerged pull request. This is not just a "what-if"). But what if I was not willing to (such as this case with OBS)? Right now, the change in pr 979 is tiny. I could just recreate it, instead of rebasing it. But what if it were not so trivial, and more, what if it were still being developed? What would be the way to automatically fetch, rebase, and merge, in the same way that you can fetch and merge branches now? (And what the heck do I say to rebase to get it to take only a portion of what happened since the last common parent, since everything since the last common parent is a no-go for me?) Once you have that rebased series in the new branch, you can merge it in (--no-ff) with a message about where the original series came from. (without the --no-ff it will just fast forward without a merge and that bit of history [the merge and it's message] will be 'lost'.) If you really want to be cute, you can create an initial merge of the pr/p897 into local master with a faked --OURS policy, so as not to loose your original series, before doing the rebase, and then add the second merge of the --no-ff rebased history. In the latter case the --first parent log should read ~~: abc123 merge: rebased pr/897 series def456 merge: original pr/987 series, pinned as second parent, using --OURS. 78code former tip commit: whatever... Exactly how to do any fixup during the rebase is another story ;-) That would be my thoughts about retaining the old as well as the new. Hope it works for you.. Philip - Original Message - From: "Michael" <keybou...@gmail.com> To: <git-users@googlegroups.com> Sent: Tuesday, August 08, 2017 3:39 AM Subject: [git-users] Adding a pull request (newer master) to my build I'm looking for how to add a pull request, based off a newer master, to my master. The specifics: I'm trying to work with OBS 18.0.2 (version 19 won't run on my older OS). I'm trying to add in a pull request (979, https://github.com/jp9000/obs-studio/pull/979 ) to my build. That pull request is based on a nearly current master, so "git merge " tries to bring in all of master. I've done this with other github stuff. I've got a version of youtube-dl,
Re: [git-users] Adding a pull request (newer master) to my build
On 2017-08-08, at 1:27 PM, Philip Oakley <philipoak...@iee.org> wrote: > Hi Michael, > > sounds like you need (one way of viewing the steps required) to rebase the > old series "take the total deltas " and apply that to a new branch taken from > 'current branch (LocalMaster)'. This (rebase) will give you a clean copy of > the series as patches (it is what rebase does beneath the covers), and add > them to the new branch. (it depends on how you want to retain the old branch > position - see later) Yea, this morning I had the idea that rebase would do it, but I don't know what arguments to use. Rebase, as I understand it, normally takes something that has a common parent, and takes everything from that common parent to the present and moves it to where you are now. What I am working with basically does not have a common parent. And I don't know how to tell that to rebase. Nor do I know how, or even if, it can track future updates to said remote branch. An example of that last one. Lets say I have a fork of youtube-dl. I have fetch targets (repositories, fetch lines) for things such as pull requests in the official repository, and updates people have made in other cloned repositories that are not currently pul requests. I can do something like git fetch git fetch johnhawk git fetch gkoelln and, if any of them updated, I could then do git checkout new git merge Disney git merge Dish to update the support for Dish and some Disney websites -- because those are remote branches that update as the other people update their public repositories. This works because I'm willing to advance master on youtube-dl (side note: I'm pulling in three remote branches and one unmerged pull request. This is not just a "what-if"). But what if I was not willing to (such as this case with OBS)? Right now, the change in pr 979 is tiny. I could just recreate it, instead of rebasing it. But what if it were not so trivial, and more, what if it were still being developed? What would be the way to automatically fetch, rebase, and merge, in the same way that you can fetch and merge branches now? (And what the heck do I say to rebase to get it to take only a portion of what happened since the last common parent, since everything since the last common parent is a no-go for me?) > > Once you have that rebased series in the new branch, you can merge it in > (--no-ff) with a message about where the original series came from. (without > the --no-ff it will just fast forward without a merge and that bit of history > [the merge and it's message] will be 'lost'.) > > If you really want to be cute, you can create an initial merge of the pr/p897 > into local master with a faked --OURS policy, so as not to loose your > original series, before doing the rebase, and then add the second merge of > the --no-ff rebased history. > > In the latter case the --first parent log should read ~~: > abc123 merge: rebased pr/897 series > def456 merge: original pr/987 series, pinned as second parent, using --OURS. > 78code former tip commit: whatever... > > Exactly how to do any fixup during the rebase is another story ;-) > > > That would be my thoughts about retaining the old as well as the new. > > Hope it works for you.. > > Philip > > - Original Message - From: "Michael" <keybou...@gmail.com> > To: <git-users@googlegroups.com> > Sent: Tuesday, August 08, 2017 3:39 AM > Subject: [git-users] Adding a pull request (newer master) to my build > > > I'm looking for how to add a pull request, based off a newer master, to my > master. > > The specifics: I'm trying to work with OBS 18.0.2 (version 19 won't run on my > older OS). I'm trying to add in a pull request (979, > https://github.com/jp9000/obs-studio/pull/979 ) to my build. > > That pull request is based on a nearly current master, so "git merge " tries > to bring in all of master. > > I've done this with other github stuff. I've got a version of youtube-dl, for > example, that includes a few prosposed pull requests. Those don't give me > trouble, because I keep updating master, and those pull requests don't add > anything that gives me trouble. > > This one? What I want seems pretty simple. I want to take the total deltas of > this (origin/pr/979) since it left origin/master, and apply that to the > current branch (LocalMaster). > > How to do that, and keep it updated if that pull request is updated, is what > I don't know how. In this case, it's unlikely to be updated, as it's already > merged into the newest master. But in general, if I'm assembling a > "frankenstein's monster" from pieces, how do I glue the pieces together? > > --- > Entertaining minecraft
Re: [git-users] Adding a pull request (newer master) to my build
Hi Michael, sounds like you need (one way of viewing the steps required) to rebase the old series "take the total deltas " and apply that to a new branch taken from 'current branch (LocalMaster)'. This (rebase) will give you a clean copy of the series as patches (it is what rebase does beneath the covers), and add them to the new branch. (it depends on how you want to retain the old branch position - see later) Once you have that rebased series in the new branch, you can merge it in (--no-ff) with a message about where the original series came from. (without the --no-ff it will just fast forward without a merge and that bit of history [the merge and it's message] will be 'lost'.) If you really want to be cute, you can create an initial merge of the pr/p897 into local master with a faked --OURS policy, so as not to loose your original series, before doing the rebase, and then add the second merge of the --no-ff rebased history. In the latter case the --first parent log should read ~~: abc123 merge: rebased pr/897 series def456 merge: original pr/987 series, pinned as second parent, using --OURS. 78code former tip commit: whatever... Exactly how to do any fixup during the rebase is another story ;-) That would be my thoughts about retaining the old as well as the new. Hope it works for you.. Philip - Original Message - From: "Michael" <keybou...@gmail.com> To: <git-users@googlegroups.com> Sent: Tuesday, August 08, 2017 3:39 AM Subject: [git-users] Adding a pull request (newer master) to my build I'm looking for how to add a pull request, based off a newer master, to my master. The specifics: I'm trying to work with OBS 18.0.2 (version 19 won't run on my older OS). I'm trying to add in a pull request (979, https://github.com/jp9000/obs-studio/pull/979 ) to my build. That pull request is based on a nearly current master, so "git merge " tries to bring in all of master. I've done this with other github stuff. I've got a version of youtube-dl, for example, that includes a few prosposed pull requests. Those don't give me trouble, because I keep updating master, and those pull requests don't add anything that gives me trouble. This one? What I want seems pretty simple. I want to take the total deltas of this (origin/pr/979) since it left origin/master, and apply that to the current branch (LocalMaster). How to do that, and keep it updated if that pull request is updated, is what I don't know how. In this case, it's unlikely to be updated, as it's already merged into the newest master. But in general, if I'm assembling a "frankenstein's monster" from pieces, how do I glue the pieces together? --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Adding a pull request (newer master) to my build
I'm looking for how to add a pull request, based off a newer master, to my master. The specifics: I'm trying to work with OBS 18.0.2 (version 19 won't run on my older OS). I'm trying to add in a pull request (979, https://github.com/jp9000/obs-studio/pull/979 ) to my build. That pull request is based on a nearly current master, so "git merge " tries to bring in all of master. I've done this with other github stuff. I've got a version of youtube-dl, for example, that includes a few prosposed pull requests. Those don't give me trouble, because I keep updating master, and those pull requests don't add anything that gives me trouble. This one? What I want seems pretty simple. I want to take the total deltas of this (origin/pr/979) since it left origin/master, and apply that to the current branch (LocalMaster). How to do that, and keep it updated if that pull request is updated, is what I don't know how. In this case, it's unlikely to be updated, as it's already merged into the newest master. But in general, if I'm assembling a "frankenstein's monster" from pieces, how do I glue the pieces together? --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
