Looking for easier way to determine diff against flutter/flutter
Opened this issue · 7 comments
Currently it's possible to compare two repositories (flutter/flutter vs Flutter-Foundation/flutter) by just using GitHub's compare functionality. It lists all the commits and allows for code diff preview.
However, the current method of keeping the Flutter-Foundation/engine and Flutter-Foundation/flutter up to date is via Pull Requests like this one. For me this creates a bit of confusion - the actual number of different commits is vastly different than the number of synchronization Pull Requests. Wondering if anyone else is having similar impression?
- Do you have any other approachable way of generating the commit diff (sort of a changelog) between the original flutter repo and Flutter-Foundation/flutter and /engine that ignores merge commits?
- If not would you consider a different way of keeping the Flutter-Foundation/flutter and /engine in sync with the main repos? Perhaps rebasing would be an option? I'm not a git expert so not sure what would be the best alternative.
Btw, thanks for making the dedicated repo for filing issues.
I believe that the pull request hack is because github doesn't let you sync in changes to github workflows, so automerge breaks. There probably is a better path. I know @matthew-carroll was looking into it.
@orestesgaolin if you have some ideas on how to fix it, I'm sure @matthew-carroll would love some help on that part.
@orestesgaolin I'm generally interested in the stated problem, and we should chat more about it. But real quick, WRT the engine, specifically, are you aware that the Flutter team is merging the engine repo into flutter/flutter?
Thanks for the quick response. I've heard of the effort to bring flutter/engine to flutter/flutter so I presume this one would follow the migration. Personally I find having to switch between 2 repos quite annoying when trying to understand how engine handles some of the platform calls, so looking forward to that.
Not being a git expert I presume it would be possible to generate a changelog of non-merge commits and update it as part of the workflow.
Moreover, @matthew-carroll mentioned yesterday during the Twitter space session, that most of the changes might be kept in a separate directory (/flock), so that also may improve clarity when it comes to comparing the changes.
Yes, we've also discussed doing the same trick flutter does to register some dependencies in the dart: space so that you can do conditional imports if you need them. That could help package authors out. I think as much as possible, having people opt in conditionally to new features should be preferred, but I think there's also a ton of room for improvements that don't change the API in the engine layer.
I looked into how that works a while back, I'll have to dig it up again, but basically it's just a little file that gets dropped down inside the dart folder on install which has some metadata about special packages
I think the approach we are using in #10 solves this problem of diffs. The end result of this approach is that you have a patches folder that lists all the patches on top of the main line flutter. The patch folder allows you to potentially pick and choose which additions you want, or take the base nest repo and create your own variants.
You can see a sample here in this test PR:
We've also wired up some hooks so that submitting a PR with a patch in the nest repo automatically applies the patch and submits a PR in the flock repo so that the patch can be viewed in context for review. Sample:
https://github.com/join-the-flock/flock/pull/7
What do you think @orestesgaolin? Does this solve this issue?