I'm wondering if there's a way I can help to keep the commit structure of
the repo a bit tidier? I can see the guideline being provided
on CONTRIBUTING.md however the current commit history could be a little
easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate
commits, e.g) and it seems the rebase before PR element of that guideline
could be better followed.
Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and
rebase commits (including adding tests appropriately for bisect) could be
helpful? Happy to put one together in the context of this project if you
think so. Also interested in any other suggestions you might have for how
this could be remedied.
I’ve actually been thinking about this a lot over the past few days, but haven’t come to any real conclusion yet.
The way I’ve traditionally worked on Foundation is that each commit has more content, and each commit is (almost) always associated with a bug. This is basically the process I had in mind when I wrote the CONTRIBUTING document.
However, we’re at such an early stage in this project now that I don’t want to add a lot of overhead to PRs that contain basic functionality. I’m also grateful for all of the work that everyone is putting in, and don’t want to put off potential contributors with an overly pedantic policy. We’re trying as hard as we can to keep up with everything, but some PRs are sitting for some time before we can fully review them, which means they are inevitably out of date and have to be rebased.
I think that as more projects start to depend upon the library we will have to be much more cautious about how we accept changes, how they are tested, and how they are structured (e.g., for easier reverting).
I welcome additional thoughts on this topic.
Thanks,
- Tony
···
On Dec 17, 2015, at 1:25 AM, Tom Jowett via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi everyone,
I'm wondering if there's a way I can help to keep the commit structure of the repo a bit tidier? I can see the guideline being provided on CONTRIBUTING.md however the current commit history could be a little easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate commits, e.g) and it seems the rebase before PR element of that guideline could be better followed.
Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and rebase commits (including adding tests appropriately for bisect) could be helpful? Happy to put one together in the context of this project if you think so. Also interested in any other suggestions you might have for how this could be remedied.
Help on rebasing would be great. I use git all the time but I still
struggle to squash my commits as I usually don't do it.
···
On Thu, Dec 17, 2015 at 9:25 AM, Tom Jowett via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote:
Hi everyone,
I'm wondering if there's a way I can help to keep the commit structure of
the repo a bit tidier? I can see the guideline being provided
on CONTRIBUTING.md however the current commit history could be a little
easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate
commits, e.g) and it seems the rebase before PR element of that guideline
could be better followed.
Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and
rebase commits (including adding tests appropriately for bisect) could be
helpful? Happy to put one together in the context of this project if you
think so. Also interested in any other suggestions you might have for how
this could be remedied.
git rebase -i is great and very well documented, with tons of blogs post about it all over the web.
if you pick `s` as a memonic it will squash and let you edit the merged commit message. If the base commit message is already good, use `f` and it will “fixup” it which is a squash where the original commit message is kept and the other one discarded.
-Pierre
···
On Dec 17, 2015, at 2:07 AM, James Campbell via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Help on rebasing would be great. I use git all the time but I still struggle to squash my commits as I usually don't do it.
On Thu, Dec 17, 2015 at 9:25 AM, Tom Jowett via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
Hi everyone,
I'm wondering if there's a way I can help to keep the commit structure of the repo a bit tidier? I can see the guideline being provided on CONTRIBUTING.md however the current commit history could be a little easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate commits, e.g) and it seems the rebase before PR element of that guideline could be better followed.
Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and rebase commits (including adding tests appropriately for bisect) could be helpful? Happy to put one together in the context of this project if you think so. Also interested in any other suggestions you might have for how this could be remedied.
Completely agree re: not wishing to be pedantic and I know this represents
such a tiny part of the overall scope of the project (ie it's much more
important that we have a full library vs a perfect commit history).
I'll try and put together a couple of scenarios based on the current
history and how they could be rebased to follow your guidelines. I'll shoot
these back to the list for everyone to look over. I'll also try cleaning up
a couple of PR's in the backlog and pushing them up to my own fork just to
walk people through they could be a bit cleaner.
All of this aside, it's really quite amazing how well this project is
coming along. Thanks for all your involvement.
Cheers,
Tom
···
On Thu, 17 Dec 2015 at 8:58 AM, Tony Parker <anthony.parker@apple.com> wrote:
Hi Tom,
I’ve actually been thinking about this a lot over the past few days, but
haven’t come to any real conclusion yet.
The way I’ve traditionally worked on Foundation is that each commit has
more content, and each commit is (almost) always associated with a bug.
This is basically the process I had in mind when I wrote the CONTRIBUTING
document.
However, we’re at such an early stage in this project now that I don’t
want to add a lot of overhead to PRs that contain basic functionality. I’m
also grateful for all of the work that everyone is putting in, and don’t
want to put off potential contributors with an overly pedantic policy.
We’re trying as hard as we can to keep up with everything, but some PRs are
sitting for some time before we can fully review them, which means they are
inevitably out of date and have to be rebased.
I think that as more projects start to depend upon the library we will
have to be much more cautious about how we accept changes, how they are
tested, and how they are structured (e.g., for easier reverting).
I welcome additional thoughts on this topic.
Thanks,
- Tony
On Dec 17, 2015, at 1:25 AM, Tom Jowett via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:
Hi everyone,
I'm wondering if there's a way I can help to keep the commit structure of
the repo a bit tidier? I can see the guideline being provided
on CONTRIBUTING.md however the current commit history could be a little
easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate
commits, e.g) and it seems the rebase before PR element of that guideline
could be better followed.
Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and
rebase commits (including adding tests appropriately for bisect) could be
helpful? Happy to put one together in the context of this project if you
think so. Also interested in any other suggestions you might have for how
this could be remedied.