[Neos] [Team] Gerrit merges

[Aske Ertmann]

Hello again

To be honest I don't know which is better fast-forward only or cherry-picking. Fast-forward keeps the SHA1 AFAIK, but doesn't add the extra information to the commit message if we'd want that. I guess it could make sense to do it like that as well.

We will of course still have build commits, but that's different IMO and we can't really avoid that unless we hook into Gerrit before merging and add the build changes to the commit directly, which would require some work and access. Also it wouldn't be general behavior for Gerrit so I'd advice against doing that.

Concerning using --rebase it doesn't matter since if something else is merged based on the same parent commit you'll get a merge commit.

Question:
It seems like we agree on this, but should we go with cherry-picking (updated commit message, new SHA1) or fast-forwaring (original commit message, original SHA1)?

+1 for cherry-picking from me

On 22/05/2013, at 10.15, Ernesto Baschny wrote:

> Christian Müller schrieb am 22.05.2013 07:40:
>> Hey,
>> 
>> On 21.05.13 23:00, Aske Ertmann wrote:
>>> Hello team
>>> 
>>> I've thought about improving commit flow since I've been a little annoyed with all the merge commits we have in our history.
>> Agreed
>>> Also Gerrit has a setting for only allowing submitting fast-forward changes. Therefore I propose that we set this to enforce only allowing changes that doesn't need a merge commit by Gerrit.
>> Sounds good, question is if we can have that just for us or if CMS Team
>> would need to have it as well?
>>> This makes the history a lot cleaner and easy to get an overview of. 
>> I thought there is always a merge commit, but great to hear that this is
>> not the case. Still we will have the build commits :/
>> 
>> So if that really helps lets try to do rebases.
> 
> This is a "per project" setting. See:
> 
> https://review.typo3.org/#/admin/projects/FLOW3/Packages/TYPO3.FLOW3
> https://review.typo3.org/#/admin/projects/TYPO3v4/Core
> 
> We at the TYPO3 CMS team use the "Cherry Pick" option, which means the
> approved change is simply cherry-picked and committed on top of the
> current HEAD.
> 
> We took that decision right from start because exactly of the reasons
> Aske is complaining. The history gets very wild if you have merges for
> every single fix. The TYPO3 CMS history is completely linear because of
> this setting
> (https://review.typo3.org/gitweb?p=TYPO3v4/Core.git;a=shortlog).
> 
> Drawback is that once merged, the commit gets a new SHA1.
> 
> Another side effect seems to be that while cherry-picking the commit
> message gets rewritten and the review information gets added to it. See:
> 
> https://review.typo3.org/gitweb?p=TYPO3v4/Core.git;a=commit;h=2030fdcf10ef75469244c467a4d77663259ee998
> 
> These lines:
> 
> Change-Id: I2192bd853a1c1fada332319812acee8fe821b78a
> Reviewed-on: https://review.typo3.org/20857
> Reviewed-by: Markus Klein
> Reviewed-by: Alexander Opitz
> Tested-by: Alexander Opitz
> Reviewed-by: Wouter Wolters
> Tested-by: Wouter Wolters
> 
> Are not in the original patch-set, just in the one that was finally
> "cherry-picked". This has been useful before (especially the Link to the
> review).
> 
> Cheers,
> Ernesto
> 
> 
> -- 
> Ernesto Baschny
> TYPO3 CMS Core Developer
> Release Manager TYPO3 4.5 & 6.2 LTS
> 
> TYPO3 .... inspiring people to share!
> Get involved: typo3.org
> _______________________________________________
> Neos mailing list
> Neos at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/neos