policy of no merges from master into PRs?

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
Dilvish
AI Lead, Programmer
Posts: 4685
Joined: Sat Sep 22, 2012 6:25 pm

Re: policy of no merges from master into PRs?

#16 Post by Dilvish » Fri Sep 25, 2015 2:38 am

As I mentioned in our GitHub discussion,
I think the history winds up slightly cleaner if we make a branch from master and merge this into that branch. Plus we agreed on a general policy of not merging master into branches and I don't see much reason here to make an exception.
I did, in one of our other threads, invite you to post here if you wanted to continue the substantive discussion. But it seems to me like you've just ignored my previous points, and also presented a misleading factual summary.
Cjkjvfnby wrote:Both branchws are not compatiable with curent test build.
And so, as I posted in our development discussion, I've already made a new experimental research branch in my repo, from current master with the older research_ai branch merged into it, so that we can continue the WIP research development there. By my testing, this is fully compatible with the current executables. Am I missing something, is there any way that this is incompatible or otherwise unsatisfactory for your purposes?

(For anyone else wanting to be involved in the discussion, the source of the incompatibility was some FOCS syntax changes made in unrelated content, so current executables won't run with the content in the older branch, but there were no conflicts or other trouble merging that older branch into a new branch off of current master, to serve as our new locus for continuing this work; it seems to me to work out fine.)
What I want:
Master merged to Dilvish often (onece a week when new test build comes or when related changed in master done).
I want to fork this branch and merge my changes to it often too.
What you suggest me to do?
Well, as I have previously noted, it seems to me the new branch already meets your current needs. If you disagree, perhaps you could explain why?

As for
Master merged to Dilvish often (onece a week when new test build comes or when related changed in master done).
If there winds up being another FOCS syntax change that makes this new branch incompatible with the then-current executables, then I can repeat this process at that time. I'm not understanding any reason for it to be done once a week.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Cjkjvfnby
AI Contributor
Posts: 448
Joined: Tue Jun 24, 2014 9:55 pm

Re: policy of no merges from master into PRs?

#17 Post by Cjkjvfnby » Fri Sep 25, 2015 5:54 pm

Dilvish wrote: Well, as I have previously noted, it seems to me the new branch already meets your current needs. If you disagree, perhaps you could explain why?
I take some research and get that I need to rebase my branch over your new branch and be happy. Does it work same if any conflicts in you rebase?

I usually merge often. I dont see any reason to work with outdated code. But if you plan to make new branch instead of merge, it will be better to make it only then required.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead, Programmer
Posts: 4685
Joined: Sat Sep 22, 2012 6:25 pm

Re: policy of no merges from master into PRs?

#18 Post by Dilvish » Fri Sep 25, 2015 8:03 pm

Cjkjvfnby wrote:I take some research and get that I need to rebase my branch over your new branch and be happy. Does it work same if any conflicts in you rebase?
I'm not understanding-- could you please rephrase?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Cjkjvfnby
AI Contributor
Posts: 448
Joined: Tue Jun 24, 2014 9:55 pm

Re: policy of no merges from master into PRs?

#19 Post by Cjkjvfnby » Fri Sep 25, 2015 8:58 pm

Dilvish wrote:
Cjkjvfnby wrote:I take some research and get that I need to rebase my branch over your new branch and be happy. Does it work same if any conflicts in you rebase?
I'm not understanding-- could you please rephrase?
We have 3 branches:
master
branch_a (master~n + m) (n commits behind master m commits ahead)
branch_b (master + m) (rebased branch_a over current master)

In that case m is same commits (same hash, same diff)
My branch (branch_a +o) can be rebased on branch_b without merges

What will happen if you have conflicts when rebase branch_a over master and I try to rebase my branch over branch_b?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead, Programmer
Posts: 4685
Joined: Sat Sep 22, 2012 6:25 pm

Re: policy of no merges from master into PRs?

#20 Post by Dilvish » Sat Sep 26, 2015 4:52 pm

Cjkjvfnby wrote:I take some research and get that I need to rebase my branch over your new branch and be happy.
It looks to me like it's pretty trivially easy to rebase your branch over the new branch (no conflicts) so sure, yes, be happy :D
Cjkjvfnby wrote:What will happen if you have conflicts when rebase branch_a over master and I try to rebase my branch over branch_b?
I think it's fairly likely that I won't be rebasing the branch again until it's done, but regardless, if we go around making more conflicts, then we'd have to deal with them, but the details of that would all depend on the details of the conflicts. The creation or avoidance of any new conflicts is pretty much in our control since this branch only touches two AI files, and I think we could probably take steps to help minimize/avoid any new conflicts. Particularly since it is looking like it might be a long involved project to get this new approach really working well, we might want to go ahead and incorporate it into master as an optional/alternate ResearchAI & the choice of which one to use could be controlled by the AI config file. This is all getting quite specific to our branch though, so if we're going to discuss this more we should take this to a separate thread rather than clutter this thread up.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply