@Shobhit_Agarwal has been making great progress on his Google Summer of Code project to refresh the Collect UI. So far, most changes have been to underlying libraries or to fix components of the UI that unambiguously needed improvement (overlapping text, things like that). Those changes have been merged incrementally to the master branch and will be part of the release coming out on July 25th.
Shobhit is now starting to make some broader changes to the look and feel that could require re-training of enumerators. To ensure that these are done in a consistent way and with community feedback, we would like to make those changes in a branch that will be approved and merged to master at the end of the summer.
I've never worked with a long-running branch like this and I'm not sure what the best strategy is for both ensuring a smooth merge at the end and preserving meaningful commit history. Since this branch will be making changes across the code base, there will be conflicts along the way.
This article describes some strategies for approaching this situation. I am currently leaning towards option 2 which would result in a lot of merge commits but is simple. A long-running branch is exactly what rerere
is for but I've never used it and it seems a little bit too magical:sparkles: for my taste. I worry that it may not always be clear what it's doing and that recovering from unexpected behavior may be difficult.
Any suggestions, preferences or advice?