search

unisonweb / unison

A friendly programming language from the future
https://unison-lang.org
Other
5.82k stars 272 forks source link

PR process revamp #2213

Closed aryairani closed 1 year ago

aryairani commented 3 years ago

UPDATE: latest design is here

No longer relevant -

There's some initial work in #2105, but we went down a rabbit hole looking at how we might embed PR bundles into github markdown, and never picked it back up again.

pchiusano commented 3 years ago

The last idea on this that I recall is that PRs are encoded as namespaces with two subnamespaces, base, and head. An anonymous namespace is created for this when pr.create is made.

.> pr.create my_new_feature29 current_trunk

<maybe show diff here of what merged result will be>

Created PR bundle #a3048b120 and pushed to https://github.com/pchiusano/unisoncode.
Use:

    pr.load https://github.com/unisonweb/pchiusano:#a3048b120

To load this PR locally.

Then pr.load loads that namespace and can intelligently provide a list of targets for the merge, based on things which have the same base as a common ancestor.

So no weird bundle format needed, and this takes advantage of the efficient syncing of namespaces that already exists.

pchiusano commented 3 years ago

Phase 1 of this should just be a timeboxed design jam / prototyping / implementation sketch of 2 days to decide on 1 or more possible approaches and better estimate level of effort.

aryairani commented 3 years ago

Ok, I like this idea.

aryairani commented 3 years ago

I closed #2105, but we might want to copy from its InputPatterns.hs.

aryairani commented 1 year ago

We(Simon and I)'re thinking that we'll just be using normal branch comparison tools to inspect and compare contributor branches. We'll sort out how to compare against the PR base vs how to compare against the current main on share. Maybe this diff would only be on Share and not something we try to do in UCM; idk tbd.