Conversation
README.md
Outdated
| - Make sure you've checked out the work branch (i.e. `feat/update_to_2_11_2), and run **git rebase --onto**, so that all UiPath customization commits are replayed onto the new Base Git Tag: | ||
|
|
||
| ```pwsh | ||
| git rebase --onto <NEW BASE Git Tag> <Our 1st customization Commit's Hash> <The work branch> |
There was a problem hiding this comment.
What should be done after rebase onto?
There was a problem hiding this comment.
Maybe squash all customisation commits? This would make the rebase easier.
There was a problem hiding this comment.
I would not squash our modification history.
Your 2nd comment is legitimate. However, the purpose of this PR is to provide the 1st iteration in the writing of the guide for Updating the Fork.
Instead of wasting a lot of time and coming up with an arbitrary plan for the final steps, it was decided (cc: @vuplea) that there will be a complementary PR the next time we need to Update the Fork. At that time, the final steps will be determined and written down.
README.md
Outdated
| | --- | --- | | ||
| |**Original corresponding commit hash:**| `d50aef95520df4216c638495a6049125c00742cb` | | ||
|
|
||
| ## Update Guide |
There was a problem hiding this comment.
Add a phrase explaining what kind of update are you referring to and the whole purpose of this chapter.
There was a problem hiding this comment.
Will do. Fwiw, it's a subheading, and its parent makes it clear what kind of update we're talking about.
README.md
Outdated
| @@ -9,6 +9,40 @@ From time to time there is a need to merge the changes from the original repo in | |||
| | --- | --- | | |||
| |**Original corresponding commit hash:**| `d50aef95520df4216c638495a6049125c00742cb` | | |||
There was a problem hiding this comment.
This refers to the hash of the newest commit authored by FreeRdp/FreeRdp, which is the parent of the oldest commit authored by UiPath/FreeRdp
eduard-dumitru
force-pushed
the
feat/docs_fork_update
branch
from
3a498f7 to
6e97490
Compare
README.md
Outdated
| git push --tags | ||
| ``` | ||
|
|
||
| A work branch should be created from `uipath` and used in the validation phase. It's name would be `feat/update_to_<NEW BASE GIT TAG>`. |
There was a problem hiding this comment.
@daniel-stanciu, can you comment?
I feel it's irrelevant if the work branch was created from the uipath branch or not. It could point to any commit. However, if it's not identical to uipath, then the git rebase --onto command will need to mention uipath as it's 4th argument, instead of the work branch.
| A work branch should be created from `uipath` and used in the validation phase. It's name would be `feat/update_to_<NEW BASE GIT TAG>`. | ||
| After checking out the branch, the rebase should be performed using the following command: | ||
| ```pwsh | ||
| git rebase --onto <NEW BASE Git Tag> <Our 1st customization Commit's Hash> <The work branch> |
There was a problem hiding this comment.
@daniel-stanciu, any thoughts on the following?:
The git rebase --onto command causes the currently checked out branch to be reset to whatever the 3 arguments dictate. <The work branch> could very well be replaced with uipath, since it's assumed is equal to it.
That would make this command description more robust to changes to the lines before it.
|
|
||
| #### Updating the fork is done on a dev machine and involves rebasing our changes on top of the new tag/branch from the original repo and **force pushing** the `uipath` branch. | ||
|
|
||
| ❗The state before the update must be saved in a support branch, named `robot/support/before_update_to_<NEW BASE GIT TAG>`, where `<NEW BASE GIT TAG>` is the tag from the original repo onto which we'll rebase our changes. |
There was a problem hiding this comment.
I was suggesting more of using the FreeRDP version, and we would have to bump the major at every upgrade, which sounds ok.
|
|
||
| The tags from the original repo must be fetched from the original repo and pushed to our fork: | ||
| ```pwsh | ||
| git fetch --tags --all |
There was a problem hiding this comment.
This git fetch is for the purpose of retrieving tags from the original FreeRDP repo. Nowhere is it specified to add that remote (and if we just clone our repo we won't have it)
eduard-dumitru
changed the title
3 participants
Documentation on how to update our FreeRDP fork.