Hi, i have a question regarding the `plugin-common...

# kontributors

[Timo Obereder]

Hi, i have a question regarding the plugin-common.xml files. Is it a responsibility of a contributor to fix those by either merge or rebase master onto the feature branch or should we just ignore those files until the feature is as its supposed to be and the reviewers will fix those before merging into master?

[dsavvinov]

We don’t have a strict policy about that, but generally it is encouraged to fix all known issues (so that branch with PR can be sent directly to our CI as-is).

In kotlin, we do only rebase-on-master, and try to avoid merge-commits as much as possible.

[Timo Obereder]

So that means i don’t need to fix those conflicts? I mean, the other possibility would be just to take the content from the master branch of those plugin files and put them in my branch instead of a full master merge or rebase.

[dsavvinov]

What do you mean by “just take the content from the master branch and put them in my branch”?

[Timo Obereder]

i mean like patching it e.g.: git checkout --patch master plugin-common.xml

[dsavvinov]

That would introduce a change authored by you in your branch, wouldn’t it? While the initial change (in master) was authored by someone else

[dsavvinov]

Maybe I lack some git-fu skills here, I must admit 🙂

[Timo Obereder]

i haven’t tried it yet but maybe copying the file content from master branch would be easier 😄

[Timo Obereder]

but id still have merge conflicts

[dsavvinov]

You shouldn’t copy it, you should rebase your changes onto master, resolve conflicts, and push resulting branch to the remote*.

This will have an exactly desired effect: master history will be left intact, and your change will be applied onto it, resulting in a clean history with all necessary for you branch changes.
(actually, the first picture from here explains it much better than me: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase 🙂 )

* note that it would require force-push, and I honestly don’t know how GitHub PR would react to that, so I’d check that PR won’t go bonkers beforehand

[dsavvinov]

Maybe there’s more ways to achieve the same thing, that’s what I’m personally using

[Timo Obereder]

used rebase on the old pr, but got all the history in the pr with it….normally do a fetch then pulling into local master from upstream master, switch to the feature branch, then do rebase. maybe i did something wrong.