[git] Write permission to branch
For a Boost submodule repository is write permission for that repository needed to create a new branch ?
On 12/08/2013 05:16 PM, Edward Diener wrote:
On 12/8/2013 11:14 AM, Edward Diener wrote:
For a Boost submodule repository is write permission for that repository needed to create a new branch ?
I should have said: to create and push a new branch.
If we assume you have a local clone that you created you should be able to make the branches you need there. Then when you push, you need to modify some remote repository, by default the one you cloned from. So you need write access to that repository. Branches are just like other changes when it comes to write access. -- Bjørn
For a Boost submodule repository is write permission for that repository needed to create a new branch ?
I should have said: to create and push a new branch.
Create locally yes, push no, not unless you're on the team for that submodule. If you're planning to submit a pull-request to the maintainer, then I believe you need to fork the repo and push to the fork... which is not as easy as it could be... unless there's some way to convert local modifications into a fork? John.
On Sun, Dec 8, 2013 at 5:54 PM, John Maddock <john@johnmaddock.co.uk> wrote:
If you're planning to submit a pull-request to the maintainer, then I believe you need to fork the repo and push to the fork... which is not as easy as it could be... unless there's some way to convert local modifications into a fork?
I believe git have a tool to generate a patch from changes between two changesets. However I never use it so I'm not sure how it works. If the project is on github it's still far easier to just click the fork button, copy the fork address and paste it in command line to push your changes there.
On 12/08/2013 05:54 PM, John Maddock wrote: ... unless there's some way to convert local
modifications into a fork?
The fork on GitHub is just a clone of the repository, much like the one you have changes in. It is a so-called /bare/ repository, i.e.: there are no checked out files - just the .git folder content. Since you are the owner of this repository, you can push your feature/whatever branch changes to it. git push <your-github-fork-url> feature/whatever See https://help.github.com/articles/pushing-to-a-remote You can also change the origin remote reference in you local repository for convenience: git remote set-url origin <your-github-fork-url> or, if you like, keep origin and make a new convenient remote reference git remote add fork <your-github-fork-url> With the latter you may push your feature/whatever branch to the "fork" remote rather than the default "origin" like this: git push fork feature/whatever The GitHub fork provide is a public place the maintainer can pull from. Any other public repository you have write access to and the maintainer could have pulled from may have done the same service - namely hosting a public accessible repository. -- Bjørn
On 12/8/2013 1:22 PM, Bjørn Roald wrote:
On 12/08/2013 05:54 PM, John Maddock wrote: ... unless there's some way to convert local
modifications into a fork?
The fork on GitHub is just a clone of the repository, much like the one you have changes in. It is a so-called /bare/ repository, i.e.: there are no checked out files - just the .git folder content. Since you are the owner of this repository, you can push your feature/whatever branch changes to it.
I created a local branch of a particular Boost repository giving it a descriptive name. This was successful. I then tried creating a repository in GitHub under my own name. This was successful and a 'master' branch was created for it. The 'master' branch is empty except for a readme.md file which GitHub commits to it. I then tried pushing my local branch to my GitHub url/master remote just created but was not able to do this. I am using TortoiseGit on Windows. For whatever reason TortoiseGit refuses to recognize that I have a 'master' branch of my new GitHub repository. It says: "Don't know what will push because unknown branch 'myremote/master'" Obviously, being a git novice, I am missing something about git. I thought one could push any local repository to any remote repository as long as one had write permission to the remote repository.
git push <your-github-fork-url> feature/whatever
See https://help.github.com/articles/pushing-to-a-remote
You can also change the origin remote reference in you local repository for convenience:
git remote set-url origin <your-github-fork-url>
or, if you like, keep origin and make a new convenient remote reference
git remote add fork <your-github-fork-url>
With the latter you may push your feature/whatever branch to the "fork" remote rather than the default "origin" like this:
git push fork feature/whatever
The GitHub fork provide is a public place the maintainer can pull from. Any other public repository you have write access to and the maintainer could have pulled from may have done the same service - namely hosting a public accessible repository.
On 12/08/2013 08:35 PM, Edward Diener wrote:
On 12/8/2013 1:22 PM, Bjørn Roald wrote:
On 12/08/2013 05:54 PM, John Maddock wrote: ... unless there's some way to convert local
modifications into a fork?
The fork on GitHub is just a clone of the repository, much like the one you have changes in. It is a so-called /bare/ repository, i.e.: there are no checked out files - just the .git folder content. Since you are the owner of this repository, you can push your feature/whatever branch changes to it.
I created a local branch of a particular Boost repository giving it a descriptive name. This was successful.
I then tried creating a repository in GitHub under my own name. This was successful and a 'master' branch was created for it. The 'master' branch is empty except for a readme.md file which GitHub commits to it.
I then tried pushing my local branch to my GitHub url/master remote just created but was not able to do this. I am using TortoiseGit on Windows. For whatever reason TortoiseGit refuses to recognize that I have a 'master' branch of my new GitHub repository. It says:
"Don't know what will push because unknown branch 'myremote/master'"
Are you using TortoiseGit, in that case see if there is a window showing the git command lines it uses. Post them. I think you get that error form some TortoiseGit layer, does not look like something I expect from the comand line push, but I may be wrong. In any case the branch 'myremote/master' part give me a hunch of what the problem is. If myremote is a reference to your remote repository fork at GitHub, then git expect: git push myremote master not git push myremote/master which uses the default remote, probably origin, so it tries git push origin myremote/master wich causes it to think myremote/master is a branch you want to push but it can't find. HTH -- Bjørn
Obviously, being a git novice, I am missing something about git. I thought one could push any local repository to any remote repository as long as one had write permission to the remote repository.
You should be able to, does not necessarily make any sense though ;-) -- bjørn
On 12/8/2013 4:49 PM, Bjørn Roald wrote:
On 12/08/2013 08:35 PM, Edward Diener wrote:
On 12/8/2013 1:22 PM, Bjørn Roald wrote:
On 12/08/2013 05:54 PM, John Maddock wrote: ... unless there's some way to convert local
modifications into a fork?
The fork on GitHub is just a clone of the repository, much like the one you have changes in. It is a so-called /bare/ repository, i.e.: there are no checked out files - just the .git folder content. Since you are the owner of this repository, you can push your feature/whatever branch changes to it.
I created a local branch of a particular Boost repository giving it a descriptive name. This was successful.
I then tried creating a repository in GitHub under my own name. This was successful and a 'master' branch was created for it. The 'master' branch is empty except for a readme.md file which GitHub commits to it.
I then tried pushing my local branch to my GitHub url/master remote just created but was not able to do this. I am using TortoiseGit on Windows. For whatever reason TortoiseGit refuses to recognize that I have a 'master' branch of my new GitHub repository. It says:
"Don't know what will push because unknown branch 'myremote/master'"
Are you using TortoiseGit, in that case see if there is a window showing the git command lines it uses. Post them.
I tried the push command anyway where the remote url has the name "myremote" for the URL https://github.com/eldiener/mplsun.git. The local branch is called "suncc" ( it is actually a Sun compiler fix for Boost MPL on its own branch ). The git command shown is: git.exe push -v --progress "myremote" suncc:master The result is: Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
I think you get that error form some TortoiseGit layer, does not look like something I expect from the comand line push, but I may be wrong. In any case the branch 'myremote/master' part give me a hunch of what the problem is. If myremote is a reference to your remote repository fork at GitHub, then git expect:
git push myremote master
not
git push myremote/master
which uses the default remote, probably origin, so it tries
git push origin myremote/master
wich causes it to think myremote/master is a branch you want to push but it can't find.
HTH -- Bjørn
Obviously, being a git novice, I am missing something about git. I thought one could push any local repository to any remote repository as long as one had write permission to the remote repository.
You should be able to, does not necessarily make any sense though ;-)
On 09/12/2013 00:00, Edward Diener wrote:
The result is:
Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details
What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
You're trying to push the local "suncc" branch to the remote "master" branch. There is already some history in the remote master branch, and your local suncc branch is not a descendant of that history. To prevent history rewriting, git is therefore refusing to branch. If you want to erase whatever is on the remote branch (which you probably do, since it only contains a dummy commit), force the push with -f.
On 12/8/2013 6:18 PM, Mathias Gaunard wrote:
On 09/12/2013 00:00, Edward Diener wrote:
The result is:
Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details
What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
You're trying to push the local "suncc" branch to the remote "master" branch. There is already some history in the remote master branch, and your local suncc branch is not a descendant of that history. To prevent history rewriting, git is therefore refusing to branch.
How was I supposed to interpret this reality from "Updates were rejected because a pushed branch tip is behind its remote" <g> ?
If you want to erase whatever is on the remote branch (which you probably do, since it only contains a dummy commit), force the push with -f.
That worked ! Thanks ! Git is still very strange to me but hopefully I will get used to its peculiarities. It does seem very flexible but very enigmatic sometimes in its so-called explanations.
On 9/12/2013 13:48, Quoth Edward Diener:
If you want to erase whatever is on the remote branch (which you probably do, since it only contains a dummy commit), force the push with -f.
That worked ! Thanks !
Git is still very strange to me but hopefully I will get used to its peculiarities. It does seem very flexible but very enigmatic sometimes in its so-called explanations.
It's easier if you create your personal GH repository as a clone/fork of the boostorg one that you're intending to modify, instead of making a new empty one (as you did). (It also works better with GH's cross-repo tracking.) If your local one was also cloned from the same source you should theoretically just have to add your GH repo as a remote and everything should mesh together nicely. (Ideally your GH repo should be your main "origin" remote but it doesn't really matter as they're all just sibling names; you just need to remember which is which when pushing/pulling.)
On 12/8/2013 9:28 PM, Gavin Lambert wrote:
On 9/12/2013 13:48, Quoth Edward Diener:
If you want to erase whatever is on the remote branch (which you probably do, since it only contains a dummy commit), force the push with -f.
That worked ! Thanks !
Git is still very strange to me but hopefully I will get used to its peculiarities. It does seem very flexible but very enigmatic sometimes in its so-called explanations.
It's easier if you create your personal GH repository as a clone/fork of the boostorg one that you're intending to modify, instead of making a new empty one (as you did). (It also works better with GH's cross-repo tracking.)
I assume there must be a way to do this on GH. Also I really don't know what the difference is when one creates another repository as a fork as opposed to cloning. Does the fork contain something the clone does not ?
If your local one was also cloned from the same source you should theoretically just have to add your GH repo as a remote and everything should mesh together nicely.
This is what I tried but since my GH repo had history git didn't like that. How odd ! Why can't it just update the history when one does a 'push' ? Why does it matter if their is previous history ? As long as their are no conflicts should not a git 'push' just work ? There is much in git that says things should be simple and just work but actually it seems it has much more checks/balances than svn had. I should have just asked for write access to the Boost MPL git repository and then I could have pretty easily created a remote branch somewhere in Boost for my own testing I think.
(Ideally your GH repo should be your main "origin" remote but it doesn't really matter as they're all just sibling names; you just need to remember which is which when pushing/pulling.)
I assume a 'remote' name is a combination of a URL and a branch and the name does not matter as long as it is unique for a given local repository.
On 9/12/2013 17:19, Quoth Edward Diener:
It's easier if you create your personal GH repository as a clone/fork of the boostorg one that you're intending to modify, instead of making a new empty one (as you did). (It also works better with GH's cross-repo tracking.)
I assume there must be a way to do this on GH. Also I really don't know what the difference is when one creates another repository as a fork as opposed to cloning. Does the fork contain something the clone does not ?
Clone and fork are basically the same thing. But from the sounds of your email neither is what you did -- you created a brand new empty repository, which is a completely different thing. When you're looking at any existing repository on GitHub there's a "clone URL" shown on the right hand side, which you can use if you want to make a clone on your local PC using standard Git tools. This typically is *not* what you want to do initially, though. At the top right is a "fork" button. If you're signed in to GH, clicking this will make a cloned repository within GH that's linked back to the original repository (which makes it easier to make pull requests or to push upstream, if you have permission to do so). Once you've created a fork on GH, that's when you should use the clone URL to check out a local copy on your machine that's linked to your repository. This way you can make changes on your local machine and push them up to your forked repository on GH, and from there make pull requests (or directly push/pull upstream if you can).
If your local one was also cloned from the same source you should theoretically just have to add your GH repo as a remote and everything should mesh together nicely.
This is what I tried but since my GH repo had history git didn't like that. How odd ! Why can't it just update the history when one does a 'push' ? Why does it matter if their is previous history ? As long as their are no conflicts should not a git 'push' just work ? There is much in git that says things should be simple and just work but actually it seems it has much more checks/balances than svn had.
It's a bit different than what you tried. And Bjørn has already explained why what you tried didn't work. You would have had the same problem in SVN. The approximate SVN equivalent action would have been to check out from one repository and then try to commit to a freshly-created blank repository elsewhere. SVN won't let you do that, because the repository ids don't match. Git *will* let you do that (because it has to work with multiple repositories, and they're all equal in its eyes), but it correctly warns you that it's a dangerous thing to do. It is a fairly common difference between Git and SVN though. SVN will typically flat-out refuse to do things it thinks are potentially dangerous. Git will initially refuse to do things too but usually provides an option to do them anyway and assume you know what you're asking for and what the consequences will be.
I assume a 'remote' name is a combination of a URL and a branch and the name does not matter as long as it is unique for a given local repository.
Yes.
Mere moments ago, quoth I:
When you're looking at any existing repository on GitHub there's a "clone URL" shown on the right hand side, which you can use if you want to make a clone on your local PC using standard Git tools. This typically is *not* what you want to do initially, though.
I should qualify that: you typically should not use the clone URL for a repository in which you intend to make public changes but you do not have rights to push. It's ok to clone something when you're just wanting read-only access (or at least you never intend to publish changes publicly), or if you do have rights to push (possibly because you've created your own fork of the "real" repository). (This isn't a hard rule of course, but as a guideline it makes life easier.)
On 12/09/2013 05:19 AM, Edward Diener wrote:
On 12/8/2013 9:28 PM, Gavin Lambert wrote:
On 9/12/2013 13:48, Quoth Edward Diener:
If you want to erase whatever is on the remote branch (which you probably do, since it only contains a dummy commit), force the push with -f.
That worked ! Thanks !
Git is still very strange to me but hopefully I will get used to its peculiarities. It does seem very flexible but very enigmatic sometimes in its so-called explanations.
It's easier if you create your personal GH repository as a clone/fork of the boostorg one that you're intending to modify, instead of making a new empty one (as you did). (It also works better with GH's cross-repo tracking.)
I assume there must be a way to do this on GH. Also I really don't know what the difference is when one creates another repository as a fork as opposed to cloning. Does the fork contain something the clone does not ?
I don't think so. To create a fork they do a clone I presume. I guess you could call a repository created with git clone a clone until you make your first change to it, then the term fork fits better.
If your local one was also cloned from the same source you should theoretically just have to add your GH repo as a remote and everything should mesh together nicely.
This is what I tried but since my GH repo had history git didn't like that. How odd ! Why can't it just update the history when one does a 'push' ? Why does it matter if their is previous history ? As long as their are no conflicts should not a git 'push' just work ?
There was conflicts as GitHub had made some history for you in the master branch.
There is much in git that says things should be simple and just work but actually it seems it has much more checks/balances than svn had.
The fact that you have more than one repository add a lot of flexibility, but there is a cost of complexity. You are best off finding patterns that work well and use them.
I should have just asked for write access to the Boost MPL git repository and then I could have pretty easily created a remote branch somewhere in Boost for my own testing I think.
Then you could just have pushed right there, a lot simpler.
(Ideally your GH repo should be your main "origin" remote but it doesn't really matter as they're all just sibling names; you just need to remember which is which when pushing/pulling.)
I assume a 'remote' name is a combination of a URL and a branch and the name does not matter as long as it is unique for a given local repository.
No, the remote is the repository url or shorthand reference like origin or your myremote. In addition you specify refspec which is a branch, a commit, a tag, or some other ref. refs live in each repository and all of them are simply pointers to a commit. Take a look in .git/refs to see how simple this system really is. When you see something like origin/master, that is not a reference to the master branch on the origin repository, but it is a ref to a local read/only copy of that remote branch as it was the last time you performed pull or fetch. These are the so-called remote tracking branches. -- Bjørn
On 12/09/2013 01:48 AM, Edward Diener wrote:
On 12/8/2013 6:18 PM, Mathias Gaunard wrote:
On 09/12/2013 00:00, Edward Diener wrote:
The result is:
Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details
What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
You're trying to push the local "suncc" branch to the remote "master" branch. There is already some history in the remote master branch, and your local suncc branch is not a descendant of that history. To prevent history rewriting, git is therefore refusing to branch.
How was I supposed to interpret this reality from "Updates were rejected because a pushed branch tip is behind its remote" <g> ?
Well, to start there is a few things to get used to. Using two different "helpful" GUI layers, github and tortoise does maybe help in most situations, but when something go wrong it make you description harder to interpret. The last listing you put here was clear as it could be and the kind of stuff you should put up to get help. Sorry I was off-line, good thing Mathis responded. The first commit in the master branch created by GitHub when you created an "empty" git repository -- shrug -- is not very helpful. It created most, if not all, of the problems for you. Basically it caused the two repositories to have conflicting histories, with no normal commonality. This commonality is normally created by clone, rather than creating a new repository and pushing into it. The latter would have been OK I think, just unusual, had the new repository really been empty -- shrug again ---. The GitHub way of cloning is to make a Fork. The command you used to push: git push myremote suncc:master does as Mathis wrote ask git to push your local suncc branch to a master branch at the remote end. This is asking remote git at github to merge your changes from your local suncc branch onto the tip of the remote master branch. If the commit at the tip of the remote master branch in its history contain commits that are not in the history of your suncc branch, then there is no trivial and safe "fast-forward" way of performing this merge, to a total replace is only option. "Updates were rejected because a pushed branch tip is behind its remote" Git refused to change history. There is no common commit in the two branches histories either. So effectively your command was more or less to change the complete history of the remote repository. It would change the tip of the master branch from the initial github commit to a completely unrelated commit, i.e.: they have no common history. As no branch or tag would point to the old master branch (the github initial commit), it would sort of be invisible and would likely be removed at some point during garbage collection. Nothing points to it any more and it is by definition garbage. Git is very careful about making garbage without you forcing it. Some advise: The GUI trying to helpfully lead you to make selections where some sensible default could have been better. Try to understand what you select, or use defaults and hope they make sense. In a command line you would less often ask for things you do not understand, because you don't know them, so I guess in this respects GUIs are not that helpful. Always do your non trivial stuff locally. I.e.: merge between local branches, don't push and ask the remote to merge. Pull or fetch, then fix branches locally as you would like them on the remote, then make sure you have tested what you have, then push the branches you want on the remote. If you only want changes in master, you merge to master locally and push master to master. If you cloned from a place you could write to, then all defaults is set up for you. If not change, the default push remote when you have one. -- Bjørn
On 09/12/2013 01:48, Edward Diener wrote:
On 12/8/2013 6:18 PM, Mathias Gaunard wrote:
On 09/12/2013 00:00, Edward Diener wrote:
The result is:
Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details
What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
You're trying to push the local "suncc" branch to the remote "master" branch. There is already some history in the remote master branch, and your local suncc branch is not a descendant of that history. To prevent history rewriting, git is therefore refusing to branch.
How was I supposed to interpret this reality from "Updates were rejected because a pushed branch tip is behind its remote" <g> ?
I personally find that "non-fast-forward" is pretty explicit.
On 12/13/2013 3:44 PM, Mathias Gaunard wrote:
On 09/12/2013 01:48, Edward Diener wrote:
On 12/8/2013 6:18 PM, Mathias Gaunard wrote:
On 09/12/2013 00:00, Edward Diener wrote:
The result is:
Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details
What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
You're trying to push the local "suncc" branch to the remote "master" branch. There is already some history in the remote master branch, and your local suncc branch is not a descendant of that history. To prevent history rewriting, git is therefore refusing to branch.
How was I supposed to interpret this reality from "Updates were rejected because a pushed branch tip is behind its remote" <g> ?
I personally find that "non-fast-forward" is pretty explicit.
I have to pick up and understand git terminology. For a relative git novice like me "non-fast forward" sounds like a reference to a recording device <g>. I am studying git to get up to speed. Printed out "Pro Git" and am slowly going through it. I do like how easy it is to create new branches, switch between branches, push and pull branches. But I am sure there is much else I do not know and I have to learn it to be comfortable with how git works.
On 08/12/2013 17:54, John Maddock wrote:
For a Boost submodule repository is write permission for that repository needed to create a new branch ?
I should have said: to create and push a new branch.
Create locally yes, push no, not unless you're on the team for that submodule.
If you're planning to submit a pull-request to the maintainer, then I believe you need to fork the repo and push to the fork... which is not as easy as it could be... unless there's some way to convert local modifications into a fork?
There is nothing to convert. You can attempt to push code to any remote repository, and you can change the default remote if you please.
participants (6)
-
Bjørn Roald -
Edward Diener -
Gavin Lambert -
John Maddock -
Klaim - Joël Lamotte -
Mathias Gaunard