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' > a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 HEAD > a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 refs/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 be pointing to 'staging-testing' and not 'master' 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. 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? 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 Implies 'master' and not 'staging-testing' I am guessing this is correct for him to deal with his upstream but not for us to make patches for the remote 'staging-testing'. The remote 'staging-testing' would always be more current or equal to remote 'master'. Now I am wondering are the sirens calling me to the rocks or will I be able to safely set anchor in the harbor? -- 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.
