|[hatari-devel] My git workflow for contributions|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: [hatari-devel] My git workflow for contributions
- From: Christian Zietz <czietz@xxxxxxx>
- Date: Sun, 20 Mar 2022 18:36:35 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1647797795; bh=rrb49acgKfUB73vwZXmmjrfbcM7HfT8B8W08FIS+GtE=; h=X-UI-Sender-Class:Date:To:From:Subject; b=Y/2kh6FFWg3Op/SlfJyElv2iIV9odX+a5kYwoxoJPXr6aA1HXzQeBh1Q6aF7ZSAVP AZ95g0zqAh72K6KUj34tyD934w/uqFo/4ThK0FgZfRVI35riAhTNqCQkARqNKTwSsM gL8mEz857r7Y3oR2mq/UpcD90MnJVsa71MFwh1BA=
There has been a lot of discussion about the pros and cons of GitHub
etc. lately. I acknowledge that this is a matter of personal taste to
which there is no clear right or wrong. Also, I do see a benefit in,
e.g., wikis or issue trackers on GitHub assuming a project has the
resources to maintain them. But personally, I fail to see why GitHub PRs
should be a superior way of contributing. I thought it would help me see
the differences if I wrote down my typical workflow for a (git-based)
project that I want to contribute to:
1. I clone the repository.
2. I create a local branch for my changes:
git checkout -b some_branch_name
3. I work on my changes, preferring to commit frequently rather than
scarcely, as it’s easier to squash commits later than to separate them.
(But separating can be done, too: git add -p.)
4. I reorder and combine my commits via git rebase -i. This is also the
stage in which I write detailed commit messages. As mentioned before, I
find that I spend significant time there and rewrite my commit messages
more often than my code changes – until I find them clear and concise.
5. I fetch the latest source from upstream:
git fetch origin master:master
6. I rebase my changes onto the latest source: git rebase origin/master
and check that they still work.
All these steps are my standard workflow, and the same regardless of the
way the project accepts contributions. Only then…
7.a) If the project wants PRs, I push my branch to a previously created
fork and go to the GitHub website to open a PR. As I’ve spent so much
time “telling a story” via commits, I hope that the maintainer does not
squash all of them.
7.b) If the project wants patches, I run git format-patch origin/master
and submit the resulting files to the mailing list.
If there are review comments that need to be addressed, I go back to step 3.
Thus, I’d say 95% of the work of a contribution is identical for me. And
for the final 5% I still cannot see why a) is preferable over b). As
stated above, I’m aware that others will see this differently. But I can
only state my personal experience from contributing to free software.
In the end, it comes down to what the maintainers like, though. They
bear a major proportion of work; so, they get to decide which is the
easiest way for them to accept contributions. As a contributor I have to
go along with their favored workflow.