Some settings can be changed outside of the config dialog. We don't
want these changes to be lost when changing the config, which
triggers reloading of the config.
BUG: 390331
rkflx |
Gwenview |
Some settings can be changed outside of the config dialog. We don't
want these changes to be lost when changing the config, which
triggers reloading of the config.
BUG: 390331
Settings changed outside the config dialog, e.g. thumbnail zoom level in Browse view,
should not reset if you change a setting in the config dialog.
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
Compared to the verbose bug report, the fix seems so simple – Awesome!
Just a small niggle, then this can land.
app/mainwindow.cpp | ||
---|---|---|
1445–1446 | Please move this to the very top, and add a linebreak below. |
Oh no, I committed this to the wrong branch, now I have to cherry-pick to stable. Normally merging from stable to master is preferred.
@huoni In case of bugfixes (no changes of user-visible strings, no new features, no change in behaviour, low risk etc.) you can do this:
git checkout Applications/17.12 arc feature a-new-feature
This will create a new branch based on the stable branch and set the stable branch as the upstream tracking branch, which will be visible via gitk --all as well as in Phabricator ("branched from").
This helps communicating to the reviewer/committer where a patch should go. Anyway, in the end it was my mistake. Oops!
I'll try to remember that!
Is this pattern consistent across KDE? I.e. master and stable?
Well, it depends ;) In general, most repositories prefer a merging strategy instead of cherry-picking (see Git history or ask for exceptions). In terms of branches, for KDE's main "products" you'll see:
See https://community.kde.org/Schedules for further insights.