https://kotlinlang.org logo
t

Timo Obereder

01/28/2019, 5:08 PM
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?
d

dsavvinov

01/29/2019, 11:27 AM
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.
t

Timo Obereder

01/29/2019, 12:26 PM
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.
d

dsavvinov

01/29/2019, 12:39 PM
What do you mean by “just take the content from the master branch and put them in my branch”?
t

Timo Obereder

01/29/2019, 12:52 PM
i mean like patching it e.g.:
git checkout --patch master plugin-common.xml
d

dsavvinov

01/29/2019, 12:53 PM
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
Maybe I lack some git-fu skills here, I must admit 🙂
t

Timo Obereder

01/29/2019, 1:00 PM
i haven’t tried it yet but maybe copying the file content from master branch would be easier 😄
but id still have merge conflicts
d

dsavvinov

01/29/2019, 1:04 PM
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
Maybe there’s more ways to achieve the same thing, that’s what I’m personally using
t

Timo Obereder

01/29/2019, 2:10 PM
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.
3 Views