(Comment is obsolete) |
(→Working with branches: FFmpeg actually follows the branch and cherry-pick from master approach, not merge up.) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
== Merging (request for discussion and inclusion on the main page) == | |||
Merging issues can be made much easier to solve with the following instructions: | |||
<code> | |||
yum install meld | |||
</code> | |||
Then configure git to use meld for merging: | |||
<code> | |||
git config --global merge.tool meld | |||
</code> | |||
Then, when merge conflicts occur, it can be resolved in a very nice, graphical interface by using the command: | |||
<code> | |||
git mergetool | |||
</code> | |||
== Working with branches == | |||
Currently we follow a ''merging-down'' strategy meaning fixes go in master and get merged down into <nowiki>f<X></nowiki> and <nowiki>f<X-1></nowiki> etc. | |||
However, this strategy can be confusing looking at the changelog of the spec file, e.g. when a rebuild happened in rawhide, which didn't take place in f<X>, but the changelog still has that entry on the f<X> branch. | |||
Of course, one could cherry pick a single commit, e.g. a version bump, down to a branch, but that would change the hashsum of the commit and hence "git branch --contains <HASH>" doesn't work anymore. | |||
Alternatively, one could follow a workflow as described in gitworkflows(7), like many project do, which would apply the version bump on the lowest branch and merging it up to master. | |||
<code> | |||
fedpkg switch-branch f25 | |||
git commit -m "version bump" | |||
fedpkg switch-branch master | |||
git merge | |||
</code> | |||
where the last step might include some conflict resolving. | |||
Latest revision as of 20:56, 12 February 2017
Merging (request for discussion and inclusion on the main page)
Merging issues can be made much easier to solve with the following instructions:
yum install meld
Then configure git to use meld for merging:
git config --global merge.tool meld
Then, when merge conflicts occur, it can be resolved in a very nice, graphical interface by using the command:
git mergetool
Working with branches
Currently we follow a merging-down strategy meaning fixes go in master and get merged down into f<X> and f<X-1> etc. However, this strategy can be confusing looking at the changelog of the spec file, e.g. when a rebuild happened in rawhide, which didn't take place in f<X>, but the changelog still has that entry on the f<X> branch. Of course, one could cherry pick a single commit, e.g. a version bump, down to a branch, but that would change the hashsum of the commit and hence "git branch --contains <HASH>" doesn't work anymore.
Alternatively, one could follow a workflow as described in gitworkflows(7), like many project do, which would apply the version bump on the lowest branch and merging it up to master.
fedpkg switch-branch f25
git commit -m "version bump"
fedpkg switch-branch master
git merge
where the last step might include some conflict resolving.