Subject: Re: [boost] [git] Write permission to branch
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-12-08 23:46:05
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk