On Thu, 17 Nov 2016 15:25:09 -0500 Walt Feasel <[email protected]> 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 obtained from remote repositories. All in all, I'd say you *need* to read a book on Git to get hold on all these stuff: how remote branches track branches in foreign repositories, and your local branches track these remote branches. The terminology is sadly confusing, but that's all we have. The "Pro Git" is freely available at <http://git-scm.com/book> -- consider reading up on branches, remote branches and synchronizing work with other repositories. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
