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 <upstream> is not specified, the upstream configured in
branch.<name>.remote and branch.<name>.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:

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.
--
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.

Reply via email to