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

[Fleetwood Farm]

On Nov 17, 2016 3:25 PM, "Walt Feasel" <waltfea...@gmail.com> 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 <waltfea...@gmail.com> 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 <waltfea...@gmail.com> 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
>

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"