![]() ![]() It keeps full history of our own changes much like normal git-merge does.It allows to manually discard/replace obsolete commits, and yet.It automatically discards commits cherry-picked to/from upstream, resulting in a shortest possible branch tracking our own changes,.This combines the best of git-merge and git-rebase: Set To Source branch jb431431 Destination branch master Title Update to upstream version ‘4.3.1’ Description Lorem ipsum dolor sit amet. Git rebase -i -onto jb431431 PREVIOUS_RESET_TO_UPSTREAM_COMMIT_OR_v4.3.1_IF_DOING_THIS_THE_VERY_FIRST_TIME Git merge -strategy ours master -m "Reset master to tag 'v4.3.1'" Both approaches may be combined in one repository, using plain merge for minor upgrades and the following approach for major upgrades. Much cleaner overview of our own changes can be achieved with the following approach, that has effect similar to using plain git-rebase while preserving ancestry relation with the replaced commits (in a way understood by Git). git merge v4.3.1 -no-ff -m " Updated to upstream version '4.3.1'. Updating to newer upstream can be done trivially with git-merge. (Also useful to later add change log items you forgot to store in pull request’s description or when the pull request was not merged in a way that preserves its description as a merge commit message.) git tag -a -m " Added initial packaging for Sailfish OS. Note: As an alternative to creating true merges for pull requests it is possible to use annotated tags to store change log entries. Use the same token later when setting up a webhook for automated build trigerring! Notice the use of the sailfish token in change log entry headers and as a tag prefix to distinguish them from upstream tags and change log entries. ![]() Added initial packaging for Sailfish OS. Set To Source branch jb424242 Destination branch master Title Add initial packaging for Sailfish OS Description Lorem ipsum dolor sit amet. Git commit -m 'Add initial packaging for Sailfish OS'Ĭreate a pull request and fill in the description in a way suitable for change log autogeneration! Example: git reset -hard v4.2Īdd our packaging files, modify code, …, push it for review. Pick a good upstream release and push to our repository initially (still without packaging). Git branch -set-upstream-to=sailfish/master master Git remote add sailfish SAILFISH_PACKAGING_URL (Assuming master is the default branch.) git remote rename origin upstream Add sailfish remote repository and set up master branch to track master branch from the sailfish remote repository. Start by cloning the upstream repository, using the name upstream to track it under Git. Patched code is in tree, is what you compile and run.Clean and minimal history of own changes can be managed, similar to maintaining a set of patches, but with proper history context.Easy to tell which changes has been cherry-picked to/from upstream.Can manage patches to/from upstream with Git.Separate history of own changes and packaging from upstream history.Compatible with GitHub-like workflows - effective use, review friendly.Use common techniques for maintaining long-lived topic branches in Git to synchronize with upstream. Tl dr: Simply keep our own changes and packaging files in one topic branch - here the topic is “Packaging for Sailfish OS”. CalDAV and CardDAV Community Contributions.Sailfish X Xperia Android 11 Build and Flash.Sailfish X Xperia Android 10 Build and Flash.Sailfish X Xperia Android 9 Build and Flash.Sailfish X Xperia Android 8 Build and Flash.Sailfish X Xperia Android 6 Build and Flash.Upstream Git with Long-Lived Topic Branch Approach.Building packages - advanced techniques. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |