github release procedure

Walter Bright newshound2 at digitalmars.com
Thu Jan 3 10:54:25 PST 2013


On 1/3/2013 3:59 AM, Jacob Carlborg wrote:
> On 2013-01-03 01:58, Walter Bright wrote:
>> 2. The:
>>
>>     git checkout staging
>>     git merge master
>>
>> It merges master into staging, wiping out my changes in staging, and
>> does not delete staging. Now that the release is done, we're done with
>> staging. What is needed is the ability to merge from staging to master
>> all commits in staging that occurred after it branched off from master.
>>
>> I did this by going through the git commit history and cherry-picking
>> one by one. There's got to be better way.
>
> Can't you just merge staging into master?

And won't that remove the commits that are in master but not in staging?


>> 3. There is no mention of where and when the:
>>
>>     git push
>>
>> and:
>>
>>     git pull
>
> Reading "Release a new version of D", I would say that after you run "git
> checkout staging" you need to make sure that you're local changes the the
> upstream changes are in sync. That can mean that you need to both run "git push"
> and "git pull".
>
> After that the tag needs to be pushed. If you then also merges master into
> staging that should be pushed as well.

I know there need to be push's and pull's. The question is the sequence, and the 
actual commands, like push origin or just push.

The trouble is the wiki lists a sequence of commands, but assumes the user 
realizes that there are a bunch of other commands that need to be interleaved.

Imagine it's a script. Steps cannot be skipped :-)


More information about the Digitalmars-d mailing list