You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2013/04/15 10:26:44 UTC
Git merge of README and RELEASE_NOTES
Hi,
Can someone go through the git steps required to merge the READ and RELEASE_NOTES files in the 4.9.1 branch into the current develop branch.
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Frédéric THOMAS <we...@hotmail.com>.
Ok, tell me what files you want to merge, I'll do that tomorrow when I wake
up, it's too now here 4:10.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, April 16, 2013 4:02 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
HI,
> if you have files with conflicts you want to merge, you will have to go by
> an intermediary branch
This is almost always going to be the case with a release as it take time to
vote on and create serval release candidates while develop work continues on
in develop.
> apparently the RELEASE_NOTES README are the same, you can check that
> running git diff develop..release4.9 RELEASE_NOTES
Both the README and RELEASE_NOTES are not the same. The develop
RELEASE_NOTES still refer to incubator when the 4.9 branch doesn't. The
README's differ by a significant amount.
> And for the rest, it comes from what I just explained
Then why is the merge of both the README and RELEASE_NOTES incorrect? The
procedure as you describe doesn't work and would overwrite more recent
changes.
For README for instance it show that this will change:
+ Apache Flex 4.9.1 is a minor update to Apache Flex 4.9.
That's correct.
But also show this will change:
-Getting the latest sources via git
+Getting the latest sources via Subversion
And this:
-
http://airdownload.adobe.com/air/mac/download/3.5/AdobeAIRSDK.tbz2
+
http://airdownload.adobe.com/air/mac/download/3.4/AdobeAIRSDK.tbz2
And this:
- This version of Apache Flex was certified for use with AIR 3.5, and
should
+ This version of Apache Flex was certified for use with AIR 3.4, and
should
be compatible with other versions of AIR newer than 3.1. However it
hasn't
- been tested on AIR 3.2, 3.3, 3.6 or 3.7.
+ been tested on AIR 3.2, 3.3 or 3.5.
And this:
- is compatible with versions 10.2 through 11.7. It has been tested
with versions 11.1
+ is compatible with versions 10.2 through 11.5. It has been tested
with versions 11.1
And many other similar changes.
It looks like it's reverting all changes we actually need - this should not
happen!
So I ask again why did git do this and more importantly what is the correct
process so these changes are not lost.
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> if you have files with conflicts you want to merge, you will have to go by an intermediary branch
This is almost always going to be the case with a release as it take time to vote on and create serval release candidates while develop work continues on in develop.
> apparently the RELEASE_NOTES README are the same, you can check that running git diff develop..release4.9 RELEASE_NOTES
Both the README and RELEASE_NOTES are not the same. The develop RELEASE_NOTES still refer to incubator when the 4.9 branch doesn't. The README's differ by a significant amount.
> And for the rest, it comes from what I just explained
Then why is the merge of both the README and RELEASE_NOTES incorrect? The procedure as you describe doesn't work and would overwrite more recent changes.
For README for instance it show that this will change:
+ Apache Flex 4.9.1 is a minor update to Apache Flex 4.9.
That's correct.
But also show this will change:
-Getting the latest sources via git
+Getting the latest sources via Subversion
And this:
- http://airdownload.adobe.com/air/mac/download/3.5/AdobeAIRSDK.tbz2
+ http://airdownload.adobe.com/air/mac/download/3.4/AdobeAIRSDK.tbz2
And this:
- This version of Apache Flex was certified for use with AIR 3.5, and should
+ This version of Apache Flex was certified for use with AIR 3.4, and should
be compatible with other versions of AIR newer than 3.1. However it hasn't
- been tested on AIR 3.2, 3.3, 3.6 or 3.7.
+ been tested on AIR 3.2, 3.3 or 3.5.
And this:
- is compatible with versions 10.2 through 11.7. It has been tested with versions 11.1
+ is compatible with versions 10.2 through 11.5. It has been tested with versions 11.1
And many other similar changes.
It looks like it's reverting all changes we actually need - this should not happen!
So I ask again why did git do this and more importantly what is the correct process so these changes are not lost.
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I want to RELEASE_NOTE and README (from the develop and release branches) into the develop branch.
But it's more about getting the process documented so we can actually make a release at some point. We want to make it as simple as possible for anyone who wants to put up there hand as a release manager.
We will need to also merge the whole release branch into develop at a future point ie after the next release.
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Frédéric THOMAS <we...@hotmail.com>.
and I just noticed as well, to check the diff on RELEASE_NOTES, use: git
diff origin/release4.9 RELEASE_NOTES
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Tuesday, April 16, 2013 3:31 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
Re wrote a bit better I hope:
As I said before, in git merge or rebase will apply only on commits, not on
files, if you have files with conflicts you want to merge, you will have to
go by an intermediary branch (temp), checkout the files you want to merge
from the branch where they are, add and commit them into the temp branch, it
will indeed add and commit files only if they are different, once committed
on a temp branch, from the develop branch you can do a git rebase, it will
stop the rebase operation on conflicts, you can then use a mergeTool if it
has been configured, you can then continue the rebase.
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Tuesday, April 16, 2013 3:23 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
> If we want to merge the entire tree would we follow the same process? (eg
> like what we have to do after a release) Do you have to do a git mergeTool
> on every file?
As I said before, in git merge or rebase will apply only on commits, not on
files, if you have files with conflicts you want to merge, you will have to
go by an intermediary branch checkout the files you want from the branch
they are, add commit them, it will indeed add and commit only if the files
are different, once committed on this temp branch, from the develop branch
you can do a git rebase, it will stop the rebase operation on conflicts, you
can then you a mergeTool if it has been configured, you can then continue
the rebase.
Obviously, if you merge or rebase an entire branch, you don't need to go by
an intermediary branch.
The good trick is to make your commits atomic, like that, you can
merge/rebase this particular commit.
> OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git
> status" only show README changed, however "git diff README" shows no
> changes, ignoring that I continue.
that means only README was changed, you can see the diff running git
diff --cached README, apparently the RELEASE_NOTES README are the same, you
can check that running git diff develop..release4.9 RELEASE_NOTES
> git add -u
Means add all my untracked files and the stages ones, that's the reason why
I ask you to be on a clean develop branch.
> A bit scary: 1 file changed, 36 insertions(+), 63 deletions(-) .
See the previous answer.
And for the rest, it comes from what I just explained, the only thing wrong
in what I wrote was 'git branch -d temp' instead of ''git branch -D temp'.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, April 16, 2013 2:39 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
Hi,
> ok, so, you need to go by an intermediary branch as git merge or rebase
> only commits
It there a simpler way of doing this? In svn it just a "svn merge" followed
by a "svn ci" - assuming you're happy with the merge.
If we want to merge the entire tree would we follow the same process? (eg
like what we have to do after a release) Do you have to do a git mergeTool
on every file?
Lets give that a try:
> git checkout -b temp
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git
status" only show README changed, however "git diff README" shows no
changes, ignoring that I continue.
> git add -u
Why is "-u" needed?
> git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"
A bit scary:
1 file changed, 36 insertions(+), 63 deletions(-)
Why did it do this when "git diff" showed no changes?
> git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 1 commit.
(use "git push" to publish your local commits)
Think that's OK.
> git rebase temp
At this point if I do a git status I get:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
Which is a little strange as I would of expected changed from the "git
checkout develop".
> git mergeTool RELEASE_NOTES
Gives "No files need merging"
So I assume no need to to do a "git rebase --continue"?
Try "git mergeTool README" and I also get "No files need merging"
This is not what I expected I know it made changes to the file in the commit
above.
git status give at this point:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
What are here 2 commits when I've only done one?
> git branch -d temp
deletes branch
If at this point if I do this "git diff --stat origin/develop" I get:
README | 99
++++++++++++++++++++++++++++++++++++---------------------------------------------------------------
RELEASE_NOTES | 26 +++++++++++++++++++++++++-
Why is it saying both README and RELEASE_NOTES have changed when only one
file was changed with the commit?
Looking at the changes (via "git diff origin/develop") to README I see that
it has merged the files incorrectly and certainly not what I expected. It's
removed the more recent changes about FP 11.7 and AIR 3.7, using git rather
than svn and changes to TLF but it did add the single line that changed the
version number 4.9 to 4.9.1. RELEASE_NOTES have similar issues. Why did this
not merge as expected?
Why did "git mergeTool" say in both cases "No files need merging" when it
obviously has (incorrectly) merged the files?
Obviously Im not an expert git user and just know enough to keep getting
myself into trouble. :-) I am just trying to understand what is going on
here as currently it really doesn't make any sense to me at all and worse
looks like it done the merge mostly in reverse?
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Frédéric THOMAS <we...@hotmail.com>.
Re wrote a bit better I hope:
As I said before, in git merge or rebase will apply only on commits, not on
files, if you have files with conflicts you want to merge, you will have to
go by an intermediary branch (temp), checkout the files you want to merge
from the branch where they are, add and commit them into the temp branch, it
will indeed add and commit files only if they are different, once committed
on a temp branch, from the develop branch you can do a git rebase, it will
stop the rebase operation on conflicts, you can then use a mergeTool if it
has been configured, you can then continue the rebase.
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Tuesday, April 16, 2013 3:23 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
> If we want to merge the entire tree would we follow the same process? (eg
> like what we have to do after a release) Do you have to do a git mergeTool
> on every file?
As I said before, in git merge or rebase will apply only on commits, not on
files, if you have files with conflicts you want to merge, you will have to
go by an intermediary branch checkout the files you want from the branch
they are, add commit them, it will indeed add and commit only if the files
are different, once committed on this temp branch, from the develop branch
you can do a git rebase, it will stop the rebase operation on conflicts, you
can then you a mergeTool if it has been configured, you can then continue
the rebase.
Obviously, if you merge or rebase an entire branch, you don't need to go by
an intermediary branch.
The good trick is to make your commits atomic, like that, you can
merge/rebase this particular commit.
> OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git
> status" only show README changed, however "git diff README" shows no
> changes, ignoring that I continue.
that means only README was changed, you can see the diff running git
diff --cached README, apparently the RELEASE_NOTES README are the same, you
can check that running git diff develop..release4.9 RELEASE_NOTES
> git add -u
Means add all my untracked files and the stages ones, that's the reason why
I ask you to be on a clean develop branch.
> A bit scary: 1 file changed, 36 insertions(+), 63 deletions(-) .
See the previous answer.
And for the rest, it comes from what I just explained, the only thing wrong
in what I wrote was 'git branch -d temp' instead of ''git branch -D temp'.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, April 16, 2013 2:39 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
Hi,
> ok, so, you need to go by an intermediary branch as git merge or rebase
> only commits
It there a simpler way of doing this? In svn it just a "svn merge" followed
by a "svn ci" - assuming you're happy with the merge.
If we want to merge the entire tree would we follow the same process? (eg
like what we have to do after a release) Do you have to do a git mergeTool
on every file?
Lets give that a try:
> git checkout -b temp
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git
status" only show README changed, however "git diff README" shows no
changes, ignoring that I continue.
> git add -u
Why is "-u" needed?
> git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"
A bit scary:
1 file changed, 36 insertions(+), 63 deletions(-)
Why did it do this when "git diff" showed no changes?
> git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 1 commit.
(use "git push" to publish your local commits)
Think that's OK.
> git rebase temp
At this point if I do a git status I get:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
Which is a little strange as I would of expected changed from the "git
checkout develop".
> git mergeTool RELEASE_NOTES
Gives "No files need merging"
So I assume no need to to do a "git rebase --continue"?
Try "git mergeTool README" and I also get "No files need merging"
This is not what I expected I know it made changes to the file in the commit
above.
git status give at this point:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
What are here 2 commits when I've only done one?
> git branch -d temp
deletes branch
If at this point if I do this "git diff --stat origin/develop" I get:
README | 99
++++++++++++++++++++++++++++++++++++---------------------------------------------------------------
RELEASE_NOTES | 26 +++++++++++++++++++++++++-
Why is it saying both README and RELEASE_NOTES have changed when only one
file was changed with the commit?
Looking at the changes (via "git diff origin/develop") to README I see that
it has merged the files incorrectly and certainly not what I expected. It's
removed the more recent changes about FP 11.7 and AIR 3.7, using git rather
than svn and changes to TLF but it did add the single line that changed the
version number 4.9 to 4.9.1. RELEASE_NOTES have similar issues. Why did this
not merge as expected?
Why did "git mergeTool" say in both cases "No files need merging" when it
obviously has (incorrectly) merged the files?
Obviously Im not an expert git user and just know enough to keep getting
myself into trouble. :-) I am just trying to understand what is going on
here as currently it really doesn't make any sense to me at all and worse
looks like it done the merge mostly in reverse?
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Frédéric THOMAS <we...@hotmail.com>.
> If we want to merge the entire tree would we follow the same process? (eg
> like what we have to do after a release) Do you have to do a git mergeTool
> on every file?
As I said before, in git merge or rebase will apply only on commits, not on
files, if you have files with conflicts you want to merge, you will have to
go by an intermediary branch checkout the files you want from the branch
they are, add commit them, it will indeed add and commit only if the files
are different, once committed on this temp branch, from the develop branch
you can do a git rebase, it will stop the rebase operation on conflicts, you
can then you a mergeTool if it has been configured, you can then continue
the rebase.
Obviously, if you merge or rebase an entire branch, you don't need to go by
an intermediary branch.
The good trick is to make your commits atomic, like that, you can
merge/rebase this particular commit.
> OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git
> status" only show README changed, however "git diff README" shows no
> changes, ignoring that I continue.
that means only README was changed, you can see the diff running git
diff --cached README, apparently the RELEASE_NOTES README are the same, you
can check that running git diff develop..release4.9 RELEASE_NOTES
> git add -u
Means add all my untracked files and the stages ones, that's the reason why
I ask you to be on a clean develop branch.
> A bit scary: 1 file changed, 36 insertions(+), 63 deletions(-) .
See the previous answer.
And for the rest, it comes from what I just explained, the only thing wrong
in what I wrote was 'git branch -d temp' instead of ''git branch -D temp'.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, April 16, 2013 2:39 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
Hi,
> ok, so, you need to go by an intermediary branch as git merge or rebase
> only commits
It there a simpler way of doing this? In svn it just a "svn merge" followed
by a "svn ci" - assuming you're happy with the merge.
If we want to merge the entire tree would we follow the same process? (eg
like what we have to do after a release) Do you have to do a git mergeTool
on every file?
Lets give that a try:
> git checkout -b temp
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git
status" only show README changed, however "git diff README" shows no
changes, ignoring that I continue.
> git add -u
Why is "-u" needed?
> git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"
A bit scary:
1 file changed, 36 insertions(+), 63 deletions(-)
Why did it do this when "git diff" showed no changes?
> git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 1 commit.
(use "git push" to publish your local commits)
Think that's OK.
> git rebase temp
At this point if I do a git status I get:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
Which is a little strange as I would of expected changed from the "git
checkout develop".
> git mergeTool RELEASE_NOTES
Gives "No files need merging"
So I assume no need to to do a "git rebase --continue"?
Try "git mergeTool README" and I also get "No files need merging"
This is not what I expected I know it made changes to the file in the commit
above.
git status give at this point:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
What are here 2 commits when I've only done one?
> git branch -d temp
deletes branch
If at this point if I do this "git diff --stat origin/develop" I get:
README | 99
++++++++++++++++++++++++++++++++++++---------------------------------------------------------------
RELEASE_NOTES | 26 +++++++++++++++++++++++++-
Why is it saying both README and RELEASE_NOTES have changed when only one
file was changed with the commit?
Looking at the changes (via "git diff origin/develop") to README I see that
it has merged the files incorrectly and certainly not what I expected. It's
removed the more recent changes about FP 11.7 and AIR 3.7, using git rather
than svn and changes to TLF but it did add the single line that changed the
version number 4.9 to 4.9.1. RELEASE_NOTES have similar issues. Why did this
not merge as expected?
Why did "git mergeTool" say in both cases "No files need merging" when it
obviously has (incorrectly) merged the files?
Obviously Im not an expert git user and just know enough to keep getting
myself into trouble. :-) I am just trying to understand what is going on
here as currently it really doesn't make any sense to me at all and worse
looks like it done the merge mostly in reverse?
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> ok, so, you need to go by an intermediary branch as git merge or rebase only commits
It there a simpler way of doing this? In svn it just a "svn merge" followed by a "svn ci" - assuming you're happy with the merge.
If we want to merge the entire tree would we follow the same process? (eg like what we have to do after a release) Do you have to do a git mergeTool on every file?
Lets give that a try:
> git checkout -b temp
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git status" only show README changed, however "git diff README" shows no changes, ignoring that I continue.
> git add -u
Why is "-u" needed?
> git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"
A bit scary:
1 file changed, 36 insertions(+), 63 deletions(-)
Why did it do this when "git diff" showed no changes?
> git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 1 commit.
(use "git push" to publish your local commits)
Think that's OK.
> git rebase temp
At this point if I do a git status I get:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
Which is a little strange as I would of expected changed from the "git checkout develop".
> git mergeTool RELEASE_NOTES
Gives "No files need merging"
So I assume no need to to do a "git rebase --continue"?
Try "git mergeTool README" and I also get "No files need merging"
This is not what I expected I know it made changes to the file in the commit above.
git status give at this point:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
What are here 2 commits when I've only done one?
> git branch -d temp
deletes branch
If at this point if I do this "git diff --stat origin/develop" I get:
README | 99 ++++++++++++++++++++++++++++++++++++---------------------------------------------------------------
RELEASE_NOTES | 26 +++++++++++++++++++++++++-
Why is it saying both README and RELEASE_NOTES have changed when only one file was changed with the commit?
Looking at the changes (via "git diff origin/develop") to README I see that it has merged the files incorrectly and certainly not what I expected. It's removed the more recent changes about FP 11.7 and AIR 3.7, using git rather than svn and changes to TLF but it did add the single line that changed the version number 4.9 to 4.9.1. RELEASE_NOTES have similar issues. Why did this not merge as expected?
Why did "git mergeTool" say in both cases "No files need merging" when it obviously has (incorrectly) merged the files?
Obviously Im not an expert git user and just know enough to keep getting myself into trouble. :-) I am just trying to understand what is going on here as currently it really doesn't make any sense to me at all and worse looks like it done the merge mostly in reverse?
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Frédéric THOMAS <we...@hotmail.com>.
ok, so, you need to go by an intermediary branch as git merge or rebase only
commits
>From your clean develop branch:
git checkout -b temp
git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
git add -u
git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"
git checkout develop
git rebase temp
git mergeTool RELEASE_NOTES
git rebase --continue
git mergeTool <FILE2>
git rebase --continue
git mergeTool <FILEX>
git rebase --continue
git branch -d temp
git push
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, April 16, 2013 12:20 AM
To: dev@flex.apache.org
Subject: Re: Git merge of README and RELEASE_NOTES
HI,
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
That just replaces the current RELEASE_NOTES file with the 4.9 one. What do
you need to do to merge the changes on both files together?
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
That just replaces the current RELEASE_NOTES file with the 4.9 one. What do you need to do to merge the changes on both files together?
Thanks,
Justin
Re: Git merge of README and RELEASE_NOTES
Posted by Frédéric THOMAS <we...@hotmail.com>.
>From your clean develop branch:
git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>
git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"
git push
-----Message d'origine-----
From: Justin Mclean
Sent: Monday, April 15, 2013 10:26 AM
To: dev@flex.apache.org
Subject: Git merge of README and RELEASE_NOTES
Hi,
Can someone go through the git steps required to merge the READ and
RELEASE_NOTES files in the 4.9.1 branch into the current develop branch.
Thanks,
Justin