- πΊπΈUnited States smustgrave
Thank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
- πΊπΈUnited States neclimdul Houston, TX
This came out of the original Drupal 8 initiatives. We where using sandboxes as a place to experiment and prep and collaborate around merge requests. There was no "merge" process at the time only patch acceptance so the idea here was to come up with a way someone making a complex change with multiple commits could get those merged instead of just committing a patch.
In a lot of ways this is resolved with issue forks, I wonder if there's a similar problem with squash commits vs preserving the history but I haven't run into the problem yet.
- π΅πͺPeru marvil07
Yes, probably replacing _core sandboxes_ with _issue forks_ leads us to the same place.
Currently for core, it seems like almost all issue fork merges are squashed into one commit.
That is definitely an improvement in git history readability comparing it to sometimes full merge and sometimes a squashed commit.To be fair that mainly happened at the start of the git transition.
As #8 highlights, the main thing is that as a community we are not that good creating patchsets.
That is maybe a consequence of the original restriction of one patch we use to have, that was dragged on into the git era.Even if we do not move to the patchset model, always squashing is the next best thing, since drupal community is good in issue granularity.
It would be amazing if we move into creating relevant patchsets instead.
Again, by patchset it is not about patches, it is a bout a set of commits that explain the changes, instead of random incremental changes. because they can help to understand better the changes, and even inspect the git history after the fact. E.g. when changing a given file, one may ask what has happened on this set of lines before, and git blame can point to the right commits, and from there more related commits can be found, which can help in the actual new development of the change being worked on.