Re: [boost] [git] Write permission to branch

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
>> 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.