On 12/10/13, 12:45 AM, Kenji Hara wrote:
> On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
>> On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
>>>     2) What is the process to update a branch with all changes
>>> master? I will need to do this because a lot of changes have occurred
>>> since the 2.065 branches were created but the actual betas are not
>>> yet prepared. Going forward, this is the only time this will occur.
>>
>> If branch does not have own commits to be preserved and needs to just
>> be synced with master state (assuming D-Programming-Language remote is
>> named `upstream`):
>>
>>    git fetch upstream # download current remote state
>>    git checkout 2.065 # go to release branch
>>    git reset --hard upstream/master # make it identical to current master
>>    git push -f origin 2.065 # update own fork
>>    git push -f upstream 2.065 # update branch in core repos, careful
>> here!
>>
>> I can't imagine any other case when one may want to update release
>> branch from master so it must the what you need.
>
> Note that, at least phobos repository already has some own commits in
> 2.065 branch.
>
> Kenji Hara

I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch.

Andrew

On Tuesday, 10 December 2013 at 05:45:26 UTC, Kenji Hara wrote:
> On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote:
>> On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote:
>>> 	2) What is the process to update a branch with all changes master? I will need to do this because a lot of changes have occurred since the 2.065 branches were created but the actual betas are not yet prepared. Going forward, this is the only time this will occur.
>>
>> If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`):
>>
>>   git fetch upstream # download current remote state
>>   git checkout 2.065 # go to release branch
>>   git reset --hard upstream/master # make it identical to current master
>>   git push -f origin 2.065 # update own fork
>>   git push -f upstream 2.065 # update branch in core repos, careful here!
>>
>> I can't imagine any other case when one may want to update release branch from master so it must the what you need.
>
> Note that, at least phobos repository already has some own commits in 2.065 branch.
>
> Kenji Hara

So, technically, there has been already some release work ongoing in that branch but now you want to restart it with new base?

    git fetch upstream
    git checkout 2.065
    git rebase upstream/master # assumes it has common point with master earlier in history
    # resolve conflicts if any
    git push -f origin 2.065 # any rewrite of history is likely to require force push
    git push -f upstream 2.065

On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:
> I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch.

cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.

On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
> On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:
>> I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch.
>
> cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.

I'd argue that the release branches should be considered public history and thus never rebased. You can always just merge master into them...

David

On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
> On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:

> cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.

Or just dropping and start again. For a first try is OK to do several trials until the things get on track.

On Tuesday, 10 December 2013 at 13:25:02 UTC, David Nadlinger wrote:
> On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote:
>> On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:
>>> I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch.
>>
>> cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.
>
> I'd argue that the release branches should be considered public history and thus never rebased. You can always just merge master into them...
>
> David

Can't agree. Release _tags_ are public. Release branches exist primarily to organize development. Merging master into release branch working on it and then merging all back to master creates very messy making it much harder to say what commits where introduces by release process.

On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
> Can't agree. Release _tags_ are public. Release branches exist primarily to organize development.

I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch?

Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option.

David

On Tuesday, 10 December 2013 at 13:37:11 UTC, David Nadlinger wrote:
> On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote:
>> Can't agree. Release _tags_ are public. Release branches exist primarily to organize development.
>
> I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch?
>
> Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option.
>
> David

It is not a problem to reset local branches on rare occasions like this one, whatever developer count is. Reason why rebasing of public branches is discouraged is not some abstract inconvenience of collaboration - it is the fact that commit hashes change in history and anything that has been pointing to part of history that got rewritten will be broken (especially important if, for example, commit hashes are embedded into deployed builds).

This is not the case here. There has not been a single tag on this branch and not a single packaged binary built from it. Just is just a development snapshot, rebasing it is no different than creating a new one. As it won't happen under normal conditions anyway, I fail to see the issue.

Dicebot, el 10 de December a las 14:01 me escribiste:
> On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote:
> >I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch.
> 
> cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.

I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy.

What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab

On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote:
> I don't understand. Rebasing the release branch on top of master
> shouldn't be an option, as it means you are taking all the changes to
> master and put them in the release branch. That's just using master as
> a release branch. The other way around would be crazy.

Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution.

> What problems do you see merging cherry-picked stuff back into master?
> IIRC git should be smart enough to recognize duplicated commits and
> ignore them, at least if you merge often.

In my experience it was not smart enough. It may have changed in latest versions of course.