[llvm-dev] Flang landing in the monorepo
Peter Waller via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 19 07:32:34 PST 2019
I take it from this conversation that we should do a --no-ff merge of
the rewritten history.
The final history will look like this:
[llvm project/master] ---------------------> [empty merge commit]
\_ 2,700ish commits _/^
This means that `git log --first-parent` will only show the merge
commit, and not those from the "initial flang" branch.
Currently it looks like I'm the person chosen to execute the rewrite,
merge and push.
So far, I know I need to coordinate with Tom & Mike for the build
emailers and the existing f18 repository to freeze submissions there.
Who is able to suspend merge-commit prohibition in github?
Alternatively, could I (github: peterwaller-arm) be given the power
temporarily whilst executing this? That way I could turn it off only for
the few minutes required to do the push, and give up the permissions
immediately after. Alternatively this could be synchronized with a phone
call or email with someone with the capability. I intend to do this in
the morning GMT (around 10:00am) leaving plenty of time in the workday
to fix problems.
If anyone else wants to coordinate with me with respect to when the
merge happens, please get in touch.
The current plan lives at
<https://github.com/flang-compiler/f18/issues/876>, if there are other
considerations please email me or comment on that thread and I will
update the check-list before it is executed.
The release branch is scheduled for Wed 15th January. I propose to
execute the plan on the Mon 13th. That gives the week beginning 6th Jan
to finalize the plans and gather any remaining feedback.
Is everyone happy with 13th January? Please speak up if not.
I'm on leave until the 6th of January and will respond to any further
comments as soon as I can after that point.
On 19/12/2019 06:20, Chris Lattner wrote:
>> On Dec 18, 2019, at 8:03 AM, James Y Knight via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> The rule against merge commits is primarily because we want to
>> encourage people to make reasonable separate commits to master which
>> are sensible (reviewable, buildable, etc) in isolation. And, to make
>> it so the history is more easily understandable to humans. It's not
>> only that we don't want merge commits -- we actually don't really
>> want people doing merges, in general.
>> But, here we actually/do/have a merge, because flang was developed
>> externally. This is an exceptional circumstance (and I'm sure we'll
>> have a few more). Using a merge commit in this circumstance makes it
>> easier for humans looking at history to understand what's going on
>> here, rather than harder -- because it actually marks the merge as
>> being a merge. That's the main reason why I think we ought to use a
>> merge commit here.
> This is a great summary of both sides of the policy, thanks James. I
More information about the llvm-dev