On 12/10/13, 10:18 AM, Dicebot wrote:
> 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.

Yes. This is precisely the case and exactly what I'm trying to achieve. My hope is that by doing this I will not be adversely effecting any code already merged into the branch. If there is a chance that this might happen, I would rather cherry-pick the items that must be included or simply forgo such inclusion until the next release.

>> 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.

On Tuesday, 10 December 2013 at 13:43:51 UTC, Dicebot wrote:
> 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 collection of "anything" includes local tracking branches people might already use, a simple "git pull" won't work anymore. Thus, it's very much not just an abstract inconvenience – it might be trivial to fix, but less Git-savy people might not immediately know how to handle the situation.

David

On Wednesday, 11 December 2013 at 09:13:05 UTC, David Nadlinger wrote:
> This collection of "anything" includes local tracking branches people might already use, a simple "git pull" won't work anymore. Thus, it's very much not just an abstract inconvenience – it might be trivial to fix, but less Git-savy people might not immediately know how to handle the situation.

That may sound very impolite but last thing I want to care about are "less Git-savy" people that refuse to learn. Resetting local tracking branch is common part of normal git workflow. It is not even advanced stuff. When I am speaking about "anything" I imply "anything released / deployed" - there is no practical value in adhering to local development branch history other than removing requirement to be familiar with `git reset` basics. If someone among developers participating in 2.065 is not familiar with it, it is a major problem in those developers, not in git flow.

I am continuously outraged by the fact that someone may find acceptable to willingly ignore one of most important tools involved in development / release process.

Dicebot, el 10 de December a las 16:18 me escribiste:
> 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.

Ah, perfect, then ignore my previous message :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ELLA FUE INFIEL, PERO EX POLOLO PAGÓ
	-- TV CHILE

On Thursday, 12 December 2013 at 15:09:12 UTC, Leandro Lucarella
wrote:
> Ah, perfect, then ignore my previous message :)

P.S. I have just made a test rebase to provide better
instructions for Andrew and can confirm that cherry-picked
commits still cause conflicts (as well as any other
same-content-but-different-hash commits). There was one such
commit in current 2.065 state

On Wednesday, 11 December 2013 at 03:12:40 UTC, Andrew Edwards
wrote:
> On 12/10/13, 10:18 AM, Dicebot wrote:
>> 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.
>
> Yes. This is precisely the case and exactly what I'm trying to achieve. My hope is that by doing this I will not be adversely effecting any code already merged into the branch. If there is a chance that this might happen, I would rather cherry-pick the items that must be included or simply forgo such inclusion until the next release.
>
>>> 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.

I think that, resetting current release branch in Phobos repo
does not cause so serious problem. So it is acceptable to me.

Kenji Hara