[llvm-dev] Flang landing in the monorepo

[Peter Waller via llvm-dev]

MLIR was merged with a 0-parent commit. I take it flang should do the same?

The only significant difference between the approaches I'm aware of is 
that if you check out a pre-llvm-merge MLIR commit, all of the checkout 
disappears aside from the MLIR sources.

Since flang was developed separately, this seems reasonable.

MLIR history:


*   0f0d0ed1c78 Import MLIR into the LLVM tree
|\
| * 5b4a01d4a63 Adjust some MLIR paths and docs
| ...
| * aed0d21a62d Create README.md
* 6f635f90929 [DWARF] Check that all fields of a Unit Header are read.

I propose to do the same as MLIR, rather than what I outlined below. 
Note that this means the flang sources will still be in a flang/ 
directory, it's just that llvm/ and other directories will be empty for 
flang commits until the point of the LLVM merge, when everything will 
behave more normally.

(In the previous approach, those directories would contain LLVM as it 
appeared at the time of the merge, which will be a fairly arbitrary 
commit. That doesn't seem very useful either.)

Regards,

- Peter

On 19/12/2019 15:32, Peter Waller via llvm-dev wrote:
> 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.
>
> Regards,
>
> - Peter
>
> 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
>> agree,
>>
>> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev