Re: [git-users] pull merge fetch rebase confusion

[Fleetwood Farm]

On Nov 18, 2016 8:09 AM, "Konstantin Khomoutov" <
flatw...@users.sourceforge.net> wrote:
>
> On Thu, 17 Nov 2016 15:25:09 -0500
> Walt Feasel  wrote:
>
> [...]
> > > > > Considering this, what do you call "staging-testing" -- a
> > > > > repository or a branch in the cloned repository?
> > > > >
> > > > I am thinking 'staging-testing' is a local copy of the remote
> > > > repository.
> [...]
> > > IOW, you could do
> > >
> > >   git checkout -b style master
> > >
> > > or
> > >
> > >   git checkout -b style HEAD
> > >
> > > and achieve exactly the same result.
> > >
> > > Or you could do, say,
> > >
> > >   git checkout -b style origin/staging-next
> > >
> > > and achieve different results because that branch points to a commit
> > > different from "master".
> > >
> > > Did you get this?
> > >
> > Yes I see what you mean.
>
> Well, sadly no. ;-)
> I'll try to explain why below.
>
> [...]
> > > I'm afraid you might have forked your "style" branch off a wrong
> > > branch: the "master" branch, which is the default, appears to point
> > > to the same commit the "staging-linus" branch points at -- while
> > > the branch "staging-testing" points at another commit.
> > >
> > > That may be OK (there were supposedly changed happened in that
> > > repository since you cloned it) but it may be something to ponder
> > > about.
> > >
> > > Did you run
> > >
> > >   git branch -a
> > >
> > > to overview both the local and remote branches you have locally?
> >
> > If I understand this correctly I would be referencing another
> > repository than the remote 'staging-testing'.
> > So if this is right 'staging-testing' could have
> > changes not yet included upstream where I am actually looking.
> > I should clarify with the maintainer that I need to be pointing to
> > 'staging-testing' and not 'master'
>
> You seem to be be confusing branches with repositories (Mercurial
> background by any chance?).  In Git, a repository might contain any
> number of branches and tags.  When you clone a repository (using the
> default settings -- that is, not passing `git clone` certain special
> command-line options which would affect its behaviour), the *whole*
> repository is cloned, and all its branches are cloned as well, and all
> the tags which happen to point to commits reachable from those branches
> are brought in as well.  The branches fetched from the remote repository
> are made into the matching "remote branches" locally.  And one local
> branch is created off the remote branch which is marked as "active" in
> the remote repository (see above).
>
> To recap; after cloning a repository, your replica contains all the
> branches from the origin repository -- just maintained in a special way
> because you're not supposed to work on them directly.
>
> > Here is my output from git branch -a
> >
> > git branch -a
> >   staging-testing
> > * style
> >   remotes/origin/HEAD -> origin/master
> >   remotes/origin/greybus-test
> >   remotes/origin/master
> >   remotes/origin/staging-linus
> >   remotes/origin/staging-next
> >   remotes/origin/staging-testing
> >
> > Which confirms what you are saying.
>
> So, as you can see, those remote/origin/* are the remote branches
> created by `git clone`.  They are here, in your local repository.
>
> You can do
>
>   git checkout -b staging-linus origin/staging-linus
>
> and have a local branch "staging-linus" created pointing to the same
> commit "origin/staging-linus" points at.
>
> Note that these are not repositories -- those are rather branches in a
> single repository.  You don't re-clone when you want to work on
> the history of another upstream branch -- you just pick another remote
> branch.
>
> When you fork a local branch off a remote branch, Git makes the local
> branch it creates "track" its source remote branch.  This is just
> writing an entry into the local repository's configuration, and it's
> just a policy: certain operations such as `git status` run on a
> tracking branch being checked out make Git consult the branch it tracks
> to report useful statistics -- like "up-to-date with" or "ahead of" or
> "behind" or "have N and M different commits each".
>
> > git checkout staging-testing
> > Switched to branch 'staging-testing'
> > Your branch is up-to-date with 'origin/staging-testing'.
> >
> > Is saying it is up to date with the repository but not
> > necessarily using remotes/origin/staging-testing?
>
> The command is telling you that your local branch "staging-testing" is
> up-to-date with the branch it tracks -- "origin/staging-testing".
> Now the way the remote branches work is that they are updated each time
> you run unadorned `git fetch origin` (and in some other cases we'll not
> touch now to keep things simple).
>
> Git never considers "up-to-date-ness" for the whole repositories
> because this typically have no sense (well, there's `git remote -v
> origin` if you like which sort of does this).
>
> The state of a local branch being up-to-date 

Re: [git-users] pull merge fetch rebase confusion

[Konstantin Khomoutov]

On Thu, 17 Nov 2016 15:25:09 -0500
Walt Feasel  wrote:

[...]
> > > > Considering this, what do you call "staging-testing" -- a
> > > > repository or a branch in the cloned repository?
> > > > 
> > > I am thinking 'staging-testing' is a local copy of the remote
> > > repository.
[...]
> > IOW, you could do
> > 
> >   git checkout -b style master
> > 
> > or
> > 
> >   git checkout -b style HEAD
> > 
> > and achieve exactly the same result.
> > 
> > Or you could do, say,
> > 
> >   git checkout -b style origin/staging-next
> > 
> > and achieve different results because that branch points to a commit
> > different from "master".
> > 
> > Did you get this?
> > 
> Yes I see what you mean.

Well, sadly no. ;-)
I'll try to explain why below.

[...]
> > I'm afraid you might have forked your "style" branch off a wrong
> > branch: the "master" branch, which is the default, appears to point
> > to the same commit the "staging-linus" branch points at -- while
> > the branch "staging-testing" points at another commit.
> > 
> > That may be OK (there were supposedly changed happened in that
> > repository since you cloned it) but it may be something to ponder
> > about.
> > 
> > Did you run
> > 
> >   git branch -a
> > 
> > to overview both the local and remote branches you have locally?
> 
> If I understand this correctly I would be referencing another
> repository than the remote 'staging-testing'.
> So if this is right 'staging-testing' could have 
> changes not yet included upstream where I am actually looking.
> I should clarify with the maintainer that I need to be pointing to
> 'staging-testing' and not 'master'

You seem to be be confusing branches with repositories (Mercurial
background by any chance?).  In Git, a repository might contain any
number of branches and tags.  When you clone a repository (using the
default settings -- that is, not passing `git clone` certain special
command-line options which would affect its behaviour), the *whole*
repository is cloned, and all its branches are cloned as well, and all
the tags which happen to point to commits reachable from those branches
are brought in as well.  The branches fetched from the remote repository
are made into the matching "remote branches" locally.  And one local
branch is created off the remote branch which is marked as "active" in
the remote repository (see above).

To recap; after cloning a repository, your replica contains all the
branches from the origin repository -- just maintained in a special way
because you're not supposed to work on them directly.

> Here is my output from git branch -a
> 
> git branch -a
>   staging-testing
> * style
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/greybus-test
>   remotes/origin/master
>   remotes/origin/staging-linus
>   remotes/origin/staging-next
>   remotes/origin/staging-testing
> 
> Which confirms what you are saying. 

So, as you can see, those remote/origin/* are the remote branches
created by `git clone`.  They are here, in your local repository.

You can do

  git checkout -b staging-linus origin/staging-linus

and have a local branch "staging-linus" created pointing to the same
commit "origin/staging-linus" points at.

Note that these are not repositories -- those are rather branches in a
single repository.  You don't re-clone when you want to work on
the history of another upstream branch -- you just pick another remote
branch.

When you fork a local branch off a remote branch, Git makes the local
branch it creates "track" its source remote branch.  This is just
writing an entry into the local repository's configuration, and it's
just a policy: certain operations such as `git status` run on a
tracking branch being checked out make Git consult the branch it tracks
to report useful statistics -- like "up-to-date with" or "ahead of" or
"behind" or "have N and M different commits each".

> git checkout staging-testing
> Switched to branch 'staging-testing'
> Your branch is up-to-date with 'origin/staging-testing'.
> 
> Is saying it is up to date with the repository but not
> necessarily using remotes/origin/staging-testing?

The command is telling you that your local branch "staging-testing" is
up-to-date with the branch it tracks -- "origin/staging-testing".
Now the way the remote branches work is that they are updated each time
you run unadorned `git fetch origin` (and in some other cases we'll not
touch now to keep things simple).

Git never considers "up-to-date-ness" for the whole repositories
because this typically have no sense (well, there's `git remote -v
origin` if you like which sort of does this).

The state of a local branch being up-to-date with the remote branch it
tracks means exactly that: the branch in the remote repository that
remote branch points at might have changed since you called `git fetch`
the last time, but that's the essense of the "D" in "DVCS": when you
work in disconnected mode, you compare your work with snapshots of the
data you 

Re: [git-users] pull merge fetch rebase confusion

[Fleetwood Farm]

On Nov 17, 2016 3:25 PM, "Walt Feasel"  wrote:
>
> On Thu, Nov 17, 2016 at 10:48:00PM +0300, Konstantin Khomoutov wrote:
> > On Thu, 17 Nov 2016 13:56:06 -0500
> > Walt Feasel  wrote:
> >
> > > On Thu, Nov 17, 2016 at 09:11:48PM +0300, Konstantin Khomoutov wrote:
> > > > On Thu, 17 Nov 2016 11:25:17 -0500
> > > > Fleetwood Farm  wrote:
> > > >
> > > > [...]
> > > > > I believe I am understanding it better already. I will need to
> > > > > reread it a few more times, and your provided links, to digest it
> > > > > all, but think I can see land through the fog now. I am never
> > > > > going to push my edits upstream as I just send email patches to
> > > > > be incorporated or not as deemed by the maintainer.
> > > >
> > > > I would then pick rebasing as the strategy to maintain your local
> > > > changes.
> > > >
> > > This is what I was thinking might be my best bet too.
> > >
> > > > > BTW, I branched my local style off of the cloned staging-testing.
> > > >
> > > > I might not understand your terminology, but
> > > >
> > > > 1) You can't clone just a single branch.
> > > >Git always clones full repositories.
> > > >
> > > >(Well, except when you perform a so-called "shallow" clone
> > > >and explicitly tell Git which branch to consider to be of
> > > >interest.  This is an advanced topic, to a degree.)
> > > >
> > > > 2) You can't fork a branch off the whole repository: any branch
> > > >either starts being orhpan, which is really a special case,
> > > >or it initially points to some existing commit -- 99.99% of all
> > > >the normal cases.
> > > >
> > > > Considering this, what do you call "staging-testing" -- a
> > > > repository or a branch in the cloned repository?
> > > >
> > > I am thinking 'staging-testing' is a local copy of the remote
> > > repository.
> > >
> > > I used
> > > 'git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git'
> > >
> > > then make the branch 'style' based on that by using 'git checkout -b
> > > style'
> >
> > Well, there's a missing bit in this puzzle.
> > Let's cite the opening paragraph of the `git clone` manual:
> >
> > | Clones a repository into a newly created directory, creates
> > | remote-tracking branches for each branch in the cloned repository
> > | (visible using git branch -r), and creates and checks out an initial
> > | branch that is forked from the cloned repository’s currently active
> > | branch.
> >
> > That's "currently active branch" is what the HEAD ref points in the
> > remote repository.
> >
> > Now consider:
> >
> >   $ git ls-remote git://.../staging.git | grep -E 'HEAD|master'
> >   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6HEAD
> >   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6refs/heads/master
> >
> > (the repo URL elided to fit into the usual message's width).
> >
> > As you can see, the HEAD ref points to the same commit the "master"
> > branch does, and that means your clone command essentially did
> >
> >   git branch master origin/master
> >
> > so you ended up with a single branch "master" tracking "origin/master"
> > and being checked out.
> >
> > The command
> >
> >   git checkout -b style
> >
> > implied the "style" branch to be created should point to the same commit
> > the HEAD ref points at, and since you had the "master" branch checked
> > out, HEAD pointed to its tip commit at that time.
> >
> > IOW, you could do
> >
> >   git checkout -b style master
> >
> > or
> >
> >   git checkout -b style HEAD
> >
> > and achieve exactly the same result.
> >
> > Or you could do, say,
> >
> >   git checkout -b style origin/staging-next
> >
> > and achieve different results because that branch points to a commit
> > different from "master".
> >
> > Did you get this?
> >
> Yes I see what you mean.
>
> > > The way I see it working, everything I do in 'style' is compared to
> > > 'staging-testing' which should be an exact copy of the remote
> > > repository.
> >
> > After looking at the output of
> >
> >   $ git ls-remote git://.../staging.git 'refs/heads/*'
> >   2bbadafbe4eacab57aa7bc8e50287c1366303807   refs/heads/greybus-test
> >   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6   refs/heads/master
> >   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6   refs/heads/staging-linus
> >   f5f4c80e9a439cd3797ccfacb8393c4d7db3bdc4   refs/heads/staging-next
> >   1a252b139eeb367c0542e20ce66948380be52623   refs/heads/staging-testing
> >
> > I'm afraid you might have forked your "style" branch off a wrong branch:
> > the "master" branch, which is the default, appears to point to the same
> > commit the "staging-linus" branch points at -- while the branch
> > "staging-testing" points at another commit.
> >
> > That may be OK (there were supposedly changed happened in that
> > repository since you cloned it) but it may be something to ponder about.
> >
> > Did you run
> >
> >   git branch -a
> >
> > to overview both the local and remote branches you 

Re: [git-users] pull merge fetch rebase confusion

[Walt Feasel]

On Thu, Nov 17, 2016 at 10:48:00PM +0300, Konstantin Khomoutov wrote:
> On Thu, 17 Nov 2016 13:56:06 -0500
> Walt Feasel  wrote:
> 
> > On Thu, Nov 17, 2016 at 09:11:48PM +0300, Konstantin Khomoutov wrote:
> > > On Thu, 17 Nov 2016 11:25:17 -0500
> > > Fleetwood Farm  wrote:
> > > 
> > > [...]
> > > > I believe I am understanding it better already. I will need to
> > > > reread it a few more times, and your provided links, to digest it
> > > > all, but think I can see land through the fog now. I am never
> > > > going to push my edits upstream as I just send email patches to
> > > > be incorporated or not as deemed by the maintainer.
> > > 
> > > I would then pick rebasing as the strategy to maintain your local
> > > changes.
> > > 
> > This is what I was thinking might be my best bet too.
> > 
> > > > BTW, I branched my local style off of the cloned staging-testing.
> > > 
> > > I might not understand your terminology, but
> > > 
> > > 1) You can't clone just a single branch.
> > >Git always clones full repositories.
> > > 
> > >(Well, except when you perform a so-called "shallow" clone
> > >and explicitly tell Git which branch to consider to be of
> > >interest.  This is an advanced topic, to a degree.)
> > > 
> > > 2) You can't fork a branch off the whole repository: any branch
> > >either starts being orhpan, which is really a special case,
> > >or it initially points to some existing commit -- 99.99% of all
> > >the normal cases.
> > > 
> > > Considering this, what do you call "staging-testing" -- a
> > > repository or a branch in the cloned repository?
> > > 
> > I am thinking 'staging-testing' is a local copy of the remote
> > repository.
> > 
> > I used
> > 'git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git'
> > 
> > then make the branch 'style' based on that by using 'git checkout -b
> > style'
> 
> Well, there's a missing bit in this puzzle.
> Let's cite the opening paragraph of the `git clone` manual:
> 
> | Clones a repository into a newly created directory, creates
> | remote-tracking branches for each branch in the cloned repository
> | (visible using git branch -r), and creates and checks out an initial
> | branch that is forked from the cloned repository’s currently active
> | branch.
> 
> That's "currently active branch" is what the HEAD ref points in the
> remote repository.
> 
> Now consider:
> 
>   $ git ls-remote git://.../staging.git | grep -E 'HEAD|master'
>   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6HEAD
>   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6refs/heads/master
> 
> (the repo URL elided to fit into the usual message's width).
> 
> As you can see, the HEAD ref points to the same commit the "master"
> branch does, and that means your clone command essentially did
> 
>   git branch master origin/master
> 
> so you ended up with a single branch "master" tracking "origin/master"
> and being checked out.
> 
> The command
> 
>   git checkout -b style
> 
> implied the "style" branch to be created should point to the same commit
> the HEAD ref points at, and since you had the "master" branch checked
> out, HEAD pointed to its tip commit at that time.
> 
> IOW, you could do
> 
>   git checkout -b style master
> 
> or
> 
>   git checkout -b style HEAD
> 
> and achieve exactly the same result.
> 
> Or you could do, say,
> 
>   git checkout -b style origin/staging-next
> 
> and achieve different results because that branch points to a commit
> different from "master".
> 
> Did you get this?
> 
Yes I see what you mean.

> > The way I see it working, everything I do in 'style' is compared to 
> > 'staging-testing' which should be an exact copy of the remote
> > repository.
> 
> After looking at the output of
> 
>   $ git ls-remote git://.../staging.git 'refs/heads/*'
>   2bbadafbe4eacab57aa7bc8e50287c1366303807   refs/heads/greybus-test
>   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6   refs/heads/master
>   a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6   refs/heads/staging-linus
>   f5f4c80e9a439cd3797ccfacb8393c4d7db3bdc4   refs/heads/staging-next
>   1a252b139eeb367c0542e20ce66948380be52623   refs/heads/staging-testing
> 
> I'm afraid you might have forked your "style" branch off a wrong branch:
> the "master" branch, which is the default, appears to point to the same
> commit the "staging-linus" branch points at -- while the branch
> "staging-testing" points at another commit.
> 
> That may be OK (there were supposedly changed happened in that
> repository since you cloned it) but it may be something to ponder about.
> 
> Did you run
> 
>   git branch -a
> 
> to overview both the local and remote branches you have locally?

If I understand this correctly I would be referencing another repository
than the remote 'staging-testing'.
So if this is right 'staging-testing' could have 
changes not yet included upstream where I am actually looking.
I should clarify with the maintainer that I need to 

Re: [git-users] pull merge fetch rebase confusion

[Konstantin Khomoutov]

On Thu, 17 Nov 2016 13:56:06 -0500
Walt Feasel  wrote:

> On Thu, Nov 17, 2016 at 09:11:48PM +0300, Konstantin Khomoutov wrote:
> > On Thu, 17 Nov 2016 11:25:17 -0500
> > Fleetwood Farm  wrote:
> > 
> > [...]
> > > I believe I am understanding it better already. I will need to
> > > reread it a few more times, and your provided links, to digest it
> > > all, but think I can see land through the fog now. I am never
> > > going to push my edits upstream as I just send email patches to
> > > be incorporated or not as deemed by the maintainer.
> > 
> > I would then pick rebasing as the strategy to maintain your local
> > changes.
> > 
> This is what I was thinking might be my best bet too.
> 
> > > BTW, I branched my local style off of the cloned staging-testing.
> > 
> > I might not understand your terminology, but
> > 
> > 1) You can't clone just a single branch.
> >Git always clones full repositories.
> > 
> >(Well, except when you perform a so-called "shallow" clone
> >and explicitly tell Git which branch to consider to be of
> >interest.  This is an advanced topic, to a degree.)
> > 
> > 2) You can't fork a branch off the whole repository: any branch
> >either starts being orhpan, which is really a special case,
> >or it initially points to some existing commit -- 99.99% of all
> >the normal cases.
> > 
> > Considering this, what do you call "staging-testing" -- a
> > repository or a branch in the cloned repository?
> > 
> I am thinking 'staging-testing' is a local copy of the remote
> repository.
> 
> I used
> 'git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git'
> 
> then make the branch 'style' based on that by using 'git checkout -b
> style'

Well, there's a missing bit in this puzzle.
Let's cite the opening paragraph of the `git clone` manual:

| Clones a repository into a newly created directory, creates
| remote-tracking branches for each branch in the cloned repository
| (visible using git branch -r), and creates and checks out an initial
| branch that is forked from the cloned repository’s currently active
| branch.

That's "currently active branch" is what the HEAD ref points in the
remote repository.

Now consider:

  $ git ls-remote git://.../staging.git | grep -E 'HEAD|master'
  a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6HEAD
  a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6refs/heads/master

(the repo URL elided to fit into the usual message's width).

As you can see, the HEAD ref points to the same commit the "master"
branch does, and that means your clone command essentially did

  git branch master origin/master

so you ended up with a single branch "master" tracking "origin/master"
and being checked out.

The command

  git checkout -b style

implied the "style" branch to be created should point to the same commit
the HEAD ref points at, and since you had the "master" branch checked
out, HEAD pointed to its tip commit at that time.

IOW, you could do

  git checkout -b style master

or

  git checkout -b style HEAD

and achieve exactly the same result.

Or you could do, say,

  git checkout -b style origin/staging-next

and achieve different results because that branch points to a commit
different from "master".

Did you get this?

> The way I see it working, everything I do in 'style' is compared to 
> 'staging-testing' which should be an exact copy of the remote
> repository.

After looking at the output of

  $ git ls-remote git://.../staging.git 'refs/heads/*'
  2bbadafbe4eacab57aa7bc8e50287c1366303807   refs/heads/greybus-test
  a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6   refs/heads/master
  a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6   refs/heads/staging-linus
  f5f4c80e9a439cd3797ccfacb8393c4d7db3bdc4   refs/heads/staging-next
  1a252b139eeb367c0542e20ce66948380be52623   refs/heads/staging-testing

I'm afraid you might have forked your "style" branch off a wrong branch:
the "master" branch, which is the default, appears to point to the same
commit the "staging-linus" branch points at -- while the branch
"staging-testing" points at another commit.

That may be OK (there were supposedly changed happened in that
repository since you cloned it) but it may be something to ponder about.

Did you run

  git branch -a

to overview both the local and remote branches you have locally?

-- 
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] pull merge fetch rebase confusion

[Walt Feasel]

On Thu, Nov 17, 2016 at 09:11:48PM +0300, Konstantin Khomoutov wrote:
> On Thu, 17 Nov 2016 11:25:17 -0500
> Fleetwood Farm  wrote:
> 
> [...]
> > I believe I am understanding it better already. I will need to reread
> > it a few more times, and your provided links, to digest it all, but
> > think I can see land through the fog now. I am never going to push my
> > edits upstream as I just send email patches to be incorporated or not
> > as deemed by the maintainer.
> 
> I would then pick rebasing as the strategy to maintain your local
> changes.
> 
This is what I was thinking might be my best bet too.

> > BTW, I branched my local style off of the cloned staging-testing.
> 
> I might not understand your terminology, but
> 
> 1) You can't clone just a single branch.
>Git always clones full repositories.
> 
>(Well, except when you perform a so-called "shallow" clone
>and explicitly tell Git which branch to consider to be of
>interest.  This is an advanced topic, to a degree.)
> 
> 2) You can't fork a branch off the whole repository: any branch
>either starts being orhpan, which is really a special case,
>or it initially points to some existing commit -- 99.99% of all
>the normal cases.
> 
> Considering this, what do you call "staging-testing" -- a repository or
> a branch in the cloned repository?
> 
I am thinking 'staging-testing' is a local copy of the remote repository.

I used 'git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git'

then make the branch 'style' based on that by using 'git checkout -b style'

The way I see it working, everything I do in 'style' is compared to 
'staging-testing' which should be an exact copy of the remote repository.

I don't make any changes to 'staging-testing' other than updating it from 
the remote.

Once 'staging-testing' is updated I would then rebase 'style'

> > I will respond back later with what I think may be my best course of
> > action after further reading and thinking.
> 
> Sure, feel free to ask away for more details where needed.

-- 
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] pull merge fetch rebase confusion

[Konstantin Khomoutov]

On Thu, 17 Nov 2016 11:25:17 -0500
Fleetwood Farm  wrote:

[...]
> I believe I am understanding it better already. I will need to reread
> it a few more times, and your provided links, to digest it all, but
> think I can see land through the fog now. I am never going to push my
> edits upstream as I just send email patches to be incorporated or not
> as deemed by the maintainer.

I would then pick rebasing as the strategy to maintain your local
changes.

> BTW, I branched my local style off of the cloned staging-testing.

I might not understand your terminology, but

1) You can't clone just a single branch.
   Git always clones full repositories.

   (Well, except when you perform a so-called "shallow" clone
   and explicitly tell Git which branch to consider to be of
   interest.  This is an advanced topic, to a degree.)

2) You can't fork a branch off the whole repository: any branch
   either starts being orhpan, which is really a special case,
   or it initially points to some existing commit -- 99.99% of all
   the normal cases.

Considering this, what do you call "staging-testing" -- a repository or
a branch in the cloned repository?

> I will respond back later with what I think may be my best course of
> action after further reading and thinking.

Sure, feel free to ask away for more details where needed.

-- 
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] pull merge fetch rebase confusion

[Fleetwood Farm]

resent as forgot to reply-all for others

On Nov 17, 2016 7:05 AM, "Konstantin Khomoutov" <
flatw...@users.sourceforge.net> wrote:
>
> On Wed, 16 Nov 2016 14:18:10 -0800 (PST)
> Walt Feasel  wrote:
>
> > I am having a really tough time determining which procedure I should
> > use to update my branches. I see conflicting advise on which is
> > better for situations cause of the log changes made.
> >
> > I think if I explain my situation it may help to guide me to the
> > correct procedure to use.
> >
> > I cloned a repository staging-testing
> >
> > I made another branch from that called style that I make all of my
> > patches from.
> >
> > So my question is which is the best way for me to update my local
> > staging-testing and my local style.
>
> OK, let's try to approach this all piecemeal.
>
> The first thing to understand is that to apply any (well, almost [*])
> approach to incorporating remote and local changes to the same line of
> development you first need to get the updated history from the remote
> repository to your local one.  This should be obvious once you think
> about the next step: no matter whether you want to use merging or
> rebasing, you will need to have "both sides" of the diverged histories
> available locally.  OK, so the command which obtains the changes from a
> remote repository is called `git fetch`, and that's what you should
> generally use as the first step.
>
> As everything in Git, `git fetch` is very flexible in what it fetches
> and what it updates locally with what it obtains.  Let's not dive into
> these complexities now; your setup is typical, and when you run
>
>   git fetch origin
>
> this command will update the so-called "remote branches" for the remote
> repository known as "origin" locally.  If you're not sure what "remote
> branches" are please read [1] first.
>
> After running the above command, you will have one or more remote
> branches updated.  None of your local branches, including "style", will
> not have been touched.  You did not tell what branch you forked your
> "style" off, so let's pretend it was "whatever".  By now you have
> history which looks like this:
>
> /->D->E->F "style"
> ...->A->B->C
> \->X->Y->Z "origin/whatever"
>
> The commit C is what the remote branch "whatever" pointed to when you
> forked "style" off it; now both you committed D..F atop of it, and
> other folks updated that branch remotely with the series of commits
> X..Z.
>
> OK, so we're approaching `git merge` and `git rebase`.
>
> Which one to use depends on many things, but two main questions to
> answer are:
>
> 1) Are you done with the changes on your "style" branch and want them
>integrated into "whatever" or you just want the changes made to
>"whatever" in the meantime be available on your "style" as well to be
>up-to-date with the upstream's progression?
>
> 2) What is your project's policy regarding merging and rebasing?
>
> Unfortunately, what to do really depends on both of them; let me
> explain why.
>
> Consider that the answer to (1) is «yes, I want "style" integrated
> upstream» and the answer to (2) is «merging are OK» or «merging is
> required».  In this case you use `git merge`:
>
>   git checkout -b whatever origin/whatever
>   git merge style
>
> The history will look like this:
>
> /->X->Y->Z-->M "whatever"
> ...->A->B->C/
> \->D->E->F-/ "style"
>
> The merge commit M brings what you've done on "style" back into
> "whatever" -- creating a so-called "diamond" in the history.
>
> You can now push "whatever" back into the remote repository -- updating
> the same-named branch there:
>
>   git push origin whatever
>
> Now condider that the answer to (2) is «no, we need linear history».
>
> You'd then use rebasing:
>
>   git checkout -b whatever origin/whatever
>   git rebase whatever style
>
> would produce
>
> ...->A->B->C->X->Y-Z->D'->E'->F' "style"
> \- "origin/whatever" and "whatever"
>
> And then you would "fast-forward" the "whatever" branch with the
> rebased commits on "style":
>
>   git checkout whatever
>   git merge style
>
> producing
>
> ...->A->B->C->X->Y-Z->D'->E'->F' "style" and "whatever"
> \- "origin/whatever"
>
> "Fast-forward" merge happens when the branch you're merging into is
> completely contained in the branch you're merging.
>
> As before, you'd now push "whatever" back to the remote repository.
>
>
> Now consider the case you'd like to just want your "style" updated to
> incorporate the changes made upstream to "whatever" in the meantime,
> and you intend to continue working on "style" and not incorporate its
> changes back upstream yet.
>
> In this case the two approaches are the same -- merging and rebasing.
>
> With rebasing, you do
>
>   git checkout -b whatever origin/whatever
>   git rebase whatever style
>
> as explained above, and that would produce
>
> ...->A->B->C->X->Y-Z->D'->E'->F' "style"

Re: [git-users] pull merge fetch rebase confusion

[Konstantin Khomoutov]

On Wed, 16 Nov 2016 14:18:10 -0800 (PST)
Walt Feasel  wrote:

> I am having a really tough time determining which procedure I should
> use to update my branches. I see conflicting advise on which is
> better for situations cause of the log changes made.
> 
> I think if I explain my situation it may help to guide me to the
> correct procedure to use.
> 
> I cloned a repository staging-testing
> 
> I made another branch from that called style that I make all of my
> patches from.
> 
> So my question is which is the best way for me to update my local 
> staging-testing and my local style.

OK, let's try to approach this all piecemeal.

The first thing to understand is that to apply any (well, almost [*])
approach to incorporating remote and local changes to the same line of
development you first need to get the updated history from the remote
repository to your local one.  This should be obvious once you think
about the next step: no matter whether you want to use merging or
rebasing, you will need to have "both sides" of the diverged histories
available locally.  OK, so the command which obtains the changes from a
remote repository is called `git fetch`, and that's what you should
generally use as the first step.

As everything in Git, `git fetch` is very flexible in what it fetches
and what it updates locally with what it obtains.  Let's not dive into
these complexities now; your setup is typical, and when you run

  git fetch origin

this command will update the so-called "remote branches" for the remote
repository known as "origin" locally.  If you're not sure what "remote
branches" are please read [1] first.

After running the above command, you will have one or more remote
branches updated.  None of your local branches, including "style", will
not have been touched.  You did not tell what branch you forked your
"style" off, so let's pretend it was "whatever".  By now you have
history which looks like this:

/->D->E->F "style"
...->A->B->C
\->X->Y->Z "origin/whatever"

The commit C is what the remote branch "whatever" pointed to when you
forked "style" off it; now both you committed D..F atop of it, and
other folks updated that branch remotely with the series of commits
X..Z.

OK, so we're approaching `git merge` and `git rebase`.

Which one to use depends on many things, but two main questions to
answer are:

1) Are you done with the changes on your "style" branch and want them
   integrated into "whatever" or you just want the changes made to
   "whatever" in the meantime be available on your "style" as well to be
   up-to-date with the upstream's progression?

2) What is your project's policy regarding merging and rebasing?

Unfortunately, what to do really depends on both of them; let me
explain why.

Consider that the answer to (1) is «yes, I want "style" integrated
upstream» and the answer to (2) is «merging are OK» or «merging is
required».  In this case you use `git merge`:

  git checkout -b whatever origin/whatever
  git merge style

The history will look like this:

/->X->Y->Z-->M "whatever"
...->A->B->C/
\->D->E->F-/ "style"

The merge commit M brings what you've done on "style" back into
"whatever" -- creating a so-called "diamond" in the history.

You can now push "whatever" back into the remote repository -- updating
the same-named branch there:

  git push origin whatever

Now condider that the answer to (2) is «no, we need linear history».

You'd then use rebasing:

  git checkout -b whatever origin/whatever
  git rebase whatever style

would produce

...->A->B->C->X->Y-Z->D'->E'->F' "style"
\- "origin/whatever" and "whatever"

And then you would "fast-forward" the "whatever" branch with the
rebased commits on "style":

  git checkout whatever
  git merge style

producing

...->A->B->C->X->Y-Z->D'->E'->F' "style" and "whatever"
\- "origin/whatever"

"Fast-forward" merge happens when the branch you're merging into is
completely contained in the branch you're merging.

As before, you'd now push "whatever" back to the remote repository.


Now consider the case you'd like to just want your "style" updated to
incorporate the changes made upstream to "whatever" in the meantime,
and you intend to continue working on "style" and not incorporate its
changes back upstream yet.

In this case the two approaches are the same -- merging and rebasing.

With rebasing, you do

  git checkout -b whatever origin/whatever
  git rebase whatever style

as explained above, and that would produce

...->A->B->C->X->Y-Z->D'->E'->F' "style"
\- "origin/whatever" and "whatever"

so that your "style" now has the X..Z commits from its upstream branch.

With merging, you need to "swap" the branches -- as you need to merge
"whatever" into "style" and not vice-versa:

  git checkout style
  git merge origin/whatever

producing

/->D->F->F-->M "style"
...->A->B->C