Again squashing is not a good technical solution as it will forbid the
next cherry-picks.
You will spend much more time to fix the next conflicts than
cherry-picking by hand now.
If you have many commits to fix docs or trivial fixes in code in the
week before release, it seems that your project is simply on time.
I'm glad to see Functest as a previous example ;)
I think the issue is simply related to the planning.
Technically speaking, you should have delayed the creation of your
stable branch (I know you can't).
Cédric
2017-10-19 16:06 GMT+02:00 Alec Hothan (ahothan) <ahot...@cisco.com>:
> Hi Yujun,
>
>
>
> The stable branch is created a few weeks before the release data and a lot
> can happen in a few weeks. It could be lots of small commits related to
> docs, lots of trivial fixes. The point I wanted to make is that you do not
> want to see all these small detail commits on your release branch and hence
> the notion of having a “clean” release branch devoid of detailed small
> commits that do not need to be tracked at that level of branch.
>
> Say you have 20 commits to fix docs or 20 trivial fixes in code in the week
> before release, will you want to have 20 commits on stable branch or one?
>
> This is a case where a merge makes sense rather than cherry picking each of
> them.
>
> Another case where merges make sense is when you deliver 5.1.0 with possibly
> lots of new enhancements to 5.0, it makes sense to merge rather than cherry
> pick lots of commits.
>
>
>
> The rebase/squash is OK too but as I noted you do not have the git pointer
> from master to release branch commit to indicate that you actually did a
> merge.
>
>
>
> Should the branch be stable state and not have too many commits at that
> stage? It depends on the type of commits and that should be left to the
> judgment of project committers. But we should allow merge commits to be
> allowed on gerrit reviews (they are not enabled today).
>
>
>
> Regards,
>
>
>
> Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: "Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com>
> Date: Wednesday, October 18, 2017 at 7:23 PM
> To: Trevor Bramwell <tbramw...@linuxfoundation.org>, "Alec Hothan (ahothan)"
> <ahot...@cisco.com>
> Cc: "opnfv-tech-discuss@lists.opnfv.org"
> <opnfv-tech-discuss@lists.opnfv.org>
> Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates
> with gerrit
>
>
>
> This could do the trick but I don't quite recommend it. There would be some
> commits on master you do NOT want to include in stable branches.
>
>
>
> I suggest to pick commits carefully after inspection and do the cherrypick
> one by one on gerrit. It will keep a record of which patch sets have been
> cherry-picked in review history (not just git log).
>
>
>
> If you have too many patch sets to be cherrypicked. Something may have gone
> wrong. By the time we created stable branch, it should be considered as a
> stable branch and not expecting too many changes, except for bug fix and
> document amending.
>
>
>
> My 2 cents.
>
>
>
> On Thu, Oct 19, 2017 at 6:04 AM Trevor Bramwell
> <tbramw...@linuxfoundation.org> wrote:
>
> Hey Alec,
>
> Here's a quick way to cherry-pick these all over to the stable/euphrates
> branch. Though you'll still need to submit them all through Gerrit:
>
> git checkout euphrates
> git cherry -v stable/euphrates master | cut -d' ' -f2 | xargs -I{} git
> cherry-pick -x '{}'
>
> 'git review' will ask you to confirm you want to upload multiple
> patchsets. A 'yes' should put all of them up for review.
>
> Regards,
> Trevor Bramwell
>
> On Wed, Oct 18, 2017 at 08:14:59PM +0000, Alec Hothan (ahothan) wrote:
>> I have many commits in master which I’d like to merge to stable/euphrates.
>> Would like to check if anybody knows how to merge master into a release
>> branch using gerrit?
>> Looks like I may need the permission to upload merges with Gerrit.
>>
>> Here is what I did:
>>
>> $ git fetch origin stable/euphrates:euphrates
>> $ git checkout euphrates
>>
>> $ git merge master –no-ff
>>
>> # at this point, so far so good, I got all my commits into my euphrates
>> branch
>>
>> # git review fails due to permission:
>>
>> $ git review
>> Warning: Permanently added
>> '[gerrit.opnfv.org]:29418,[198.145.29.81]:29418' (RSA) to the list of known
>> hosts.
>> remote: Processing changes: refs: 1, done
>> To ssh://gerrit.opnfv.org:29418/nfvbench.git
>> ! [remote rejected] HEAD -> refs/publish/master/euphrates (you are not
>> allowed to upload merges)
>> error: failed to push some refs to
>> 'ssh://ahot...@gerrit.opnfv.org:29418/nfvbench.git'
>>
>>
>> Is there a different way to achieve this?
>> I do not want to cherry pick my commits as I have too many of them.
>>
>> Thanks
>>
>> Alec
>>
>
>> _______________________________________________
>> opnfv-tech-discuss mailing list
>> opnfv-tech-discuss@lists.opnfv.org
>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> _______________________________________________
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> --
>
> Yujun Zhang
>
>
> _______________________________________________
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
_______________________________________________
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
