A branch question

A branch question

[J. R. Westmoreland]

hi everyone

I have found a solution which may not be the best so I’m asking it here to see if I get a different solution from the wizards group. :)

I have a number of repos that were converted from svn to git. After the conversion the branches that contained each release were named something like “branches/version_<version-number>”. We want to modify the repo so the branches are named something like “release/<version-number>”. 

I currently do a command sequence like this:
git checkout <existing-branch>
git branch -m <existing-branch> <new-branch>
git push origin :<old-branch>
git push origin <new-branch>
Then I do a:
git checkout master
git branch -D <new-branch>
to cleanup my local area.

Note: These branches are only kept for historical purposes and not modified except occasionally the latest release may have an update so fix a bug.

Finally, as we move forward, what is the accepted best practice for doing a release?

Thanks in advance for your collective wisdom.

Best,
J. R.

Re: A branch question

[Junio C Hamano]

"J. R. Westmoreland" <jr@jrw.org> writes:

> I have a number of repos that were converted from svn to git. After
> the conversion the branches that contained each release were named
> something like “branches/version_<version-number>”. We want to
> modify the repo so the branches are named something like
> “release/<version-number>”.
>
> I currently do a command sequence like this:
> git checkout <existing-branch>
> git branch -m <existing-branch> <new-branch>
> git push origin :<old-branch>
> git push origin <new-branch>
> Then I do a:
> git checkout master
> git branch -D <new-branch>
> to cleanup my local area.
>
> Note: These branches are only kept for historical purposes and not
> modified except occasionally the latest release may have an update so
> fix a bug.
>
> Finally, as we move forward, what is the accepted best practice for doing a release?

A few comments:

 1. You can rename a branch without checking it out, can't you?

    $ git branch -m version_1.0 v1.0
    $ git branch -m version_1.1 v1.1
    ...

 2. If you want to only correct what is shown at origin to the other
    people, then you do not have to update your local repository.

    $ git push origin version_1.0 v1.0
    $ git push origin version_1.1 v1.1
    ...

 3. If these old ones are meant to be immutable, then storing them as
    tags instead of leaving them as branches might make more sense,
    i.e.

    $ git push origin version_1.0 tags/v1.0
    $ git push origin version_1.1 tags/v1.1
    ...

   If you are still actively maintaining an older release, you would
   still want to have release points marked on the maintenance
   branch, so 2. and 3. can be combined.  Branch v1.0 may be used to
   backport fixes to produce v1.0.x releases, each of which would be
   tagged individually, perhaps like this:

    $ git checkout version_1.0
    
    : rename it to maint-1.0 to clarify this is for 1.0.x series
    : maintenance
    $ git branch -m maint-1.0

    : tag the released version, with GPG signature
    $ git tag -s v1.0 maint-1.0

    : push the whole thing out
    $ git push origin maint-1.0 v1.0

    : when it is time to do more on the older maintenance track
    $ git checkout maint-1.0
    : hack hack hack to prepare maintenance release
    $ git commit

    : sign the release tag
    $ git tag -s v1.0.1

    : push the whole thing out
    $ git push origin maint-1.0 v1.0.1


3. is what I would be using if I were you.

Re: A branch question

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>  2. If you want to only correct what is shown at origin to the other
>     people, then you do not have to update your local repository.
>
>     $ git push origin version_1.0 v1.0
>     $ git push origin version_1.1 v1.1

Colons are missing from this one.

	git push $there $we_call_it_so:$they_call_it_so

i.e.

	git push origin version_1.0:v1.0        
	...

>  3. If these old ones are meant to be immutable, then storing them as
>     tags instead of leaving them as branches might make more sense,
>     i.e.
>
>     $ git push origin version_1.0 tags/v1.0
>     $ git push origin version_1.1 tags/v1.1

Likewise.