Thank you all for the constructive and helpful comments!
Cedric said what I did not dare to say openly: my stable branch was created too
early, which is causing this need to do a merge (heck, I even needed a fast
forward merge of my stable branch). I did not like it a bit that
Hi, Alec
See my additional comments.
On Thu, Oct 19, 2017 at 10:06 PM Alec Hothan (ahothan)
wrote:
> 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,
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
Hello Alec,
Yes Functest conforms with the "classical" guidelines as we "cherry-pick"
the commits from master to stable/euphrates.
It results in small commits because all are small bugfixes before the
release. That's the best way to easily maintain the branches.
Ii could be noted that we also
On Wed, October 18, 2017 at 7:23 PM, Yujun Zhang (ZTE) wrote:
> 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
There are different approaches to handling those “cherry-picks” or “merges”
from master to stable.
My experience may be old fashioned, but worked very well and quite clean:
- If a commit needs to be “cherry-picked” or “merged” into stable,
either doc or bug fix or feature enhancement,
Cedric,
This openstack document describes the normal dev workflow. The Merge section in
the document is related to what Gerrit does when a patchset is +2. In this
thread, we’re talking about the ability to submit a merge request to Gerrit (so
this is before +2 is done).
The notion of branch
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
Hello,
I would advice the offical OpenStack documentation about this topic:
https://docs.openstack.org/infra/manual/developers.html
Cédric
2017-10-19 4:23 GMT+02:00 Yujun Zhang (ZTE) :
> This could do the trick but I don't quite recommend it. There would be some
>
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
Hi,
Not really. A squashed commit will be just that – a single commit, optionally
keeping the commit titles and/or descriptions of all the patches, but no
further code separation.
It’s basically one big patch, with all commit metdata concatenated.
If you are after a link between the commits on
Alex,
Ross has proposed a method using rebase, is that what you are also proposing?
It is still not quite same as a merge (see my reply to Ross).
Thanks
Alec
From: Alexandru Avadanii
Date: Wednesday, October 18, 2017 at 4:20 PM
To: "Alec Hothan (ahothan)"
Hi Ross,
I tried the rebase path and it seems to work.
The rebase duplicates all commits of master to the euphrates branch which can
make that branch very busy.
It is possible to squash all commits into 1 (which is what I’d like to keep the
release branch clean).
In any case, the main
Hi, Alec,
If all you want is one commit on the stable branch, you should look at
squashing all commits from master into a single commit on the stable branch.
Alex
From: opnfv-tech-discuss-boun...@lists.opnfv.org
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Alec Hothan
Hi Trevor,
Thanks for the tip!
If I am not mistaken that will result in as many commits in euphrates as there
are commits to cherry-pick from master?
Although you achieve the same final state in stable/euphrates you do end up
with potentially significantly more commits than a simple merge. I
git remote update
# create new branch based on master
git checkout -B euphrates-sync-$(date -I) origin/master
# rebase on euphrates
git rebase origin/stable/euphrates
# or to pick patches
git rebase -i origin/stable/euphrates
# resolve conflicts
# submit all patches to gerrit
git review
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
+Aric, Trevor
Aric or Trevor - could you please advise Alec?
On Wed, Oct 18, 2017 at 1:14 PM, 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
18 matches
Mail list logo