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 <destination> <start> <end>
> 
> where <destination> is either:
> the <<branched from branch>> or
> <first useful commit>^ (i.e. parent of)
> 
> if <end> is omited, then HEAD is assumed.
> 
> 
> Interactive
> 
> git rebase -i <after-this-commit>
> --
> 
> 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, 
>> 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.

Reply via email to