Tor Arne Vestbø [off-list ref] writes:
If you would like to contribute to the stable 1.6 branch, do:
$ git clone -n git://git.foo.com/project.git
$ cd project
$ git checkout -t origin/1.6
$ git branch -D master
Which is not so nice and inviting.
If you are working on 1.6 maintenance track, why discard 'master'? If the
upstream project calls it 1.6, you can call your fork 1.6 and keep that
checked out.
IOW, _you_ are make it not nice.
Junio C Hamano wrote:
Tor Arne Vestbø [off-list ref] writes:
quoted
If you would like to contribute to the stable 1.6 branch, do:
$ git clone -n git://git.foo.com/project.git
$ cd project
$ git checkout -t origin/1.6
$ git branch -D master
Which is not so nice and inviting.
If you are working on 1.6 maintenance track, why discard 'master'?
One example I can think of is if master is moving a lot faster than the
maintenance track, and you are not interested in master.
[box:/tmp/downstream] $ git branch
* 1.6
master
[box:/tmp/downstream] $ git pull --rebase
Current branch 1.6 is up to date.
[box:/tmp/downstream] $ git push
To file:///tmp/upstream
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'file:///tmp/upstream'
In that case you would either have to ff master all the time (requiring
a checkout or rebase magic), or do an explicit "git push origin 1.6".
Neither good options when you are trying to teach people that git push
is the way you submit changes.
Tor Arne