github release procedure
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
>> 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