When several persons work together on a project shared in repositories in github, it happens quite often that I feel that someone else’s code is hard to read, and want to change and reorganize his code and add more comments.
It is for improving readability just for my own purpose, and I don’t want to ask others to change their code in the same way that I change it.
If I keep a local copy of their code and modify their code to help me better understand it, I am not sure how to manage the local copy as the project goes on and I need to change their code again and again and thus have more and more local copies of their code that are modified for my understanding purpose.
What shall I do with the above problem?
Thanks.
4
If I keep a local copy of their code and modify their code to help me better understand it, I am not sure how to manage the local copy as the project goes on and I need to change their code again and again and thus have more and more local copies of their code that are modified for my understanding purpose.
The maintenance burden is perhaps the #1 reason this is not done. People who add features to an open source software are very eager to get their changes merged upstream so that they don’t have to deal with an endless stream of conflicts for their patches.
The correct tool for maintaining a patch set, regardless of your motivation for doing so, is git rebase. See here: https://git-scm.com/book/en/v2/Git-Branching-Rebasing.
1
It’s possible to maintain a patchset by creating a separate branch and periodically rebasing or merging master into it. If you branch off of it to do any work that you will submit upstream, you have to rebase --onto master before pushing. People use this approach to maintain patches in open source projects that they can’t or won’t submit upstream.
The big problem with this approach is it requires a very thorough understanding of both your branch and the upstream branch, because this system produces crazy difficult merge conflicts sometimes. That makes it ill-suited for your use case.
That’s why I would recommend making changes in a branch as a learning exercise, but don’t worry about maintaining them over time. Also, please consider if there are true maintainability changes and not just style changes, submitting those for everyone’s benefit. Quite often, my commit pattern goes:
- Refactor existing code so I can understand it better.
- Implement the feature.
- Refactor the new feature so it is cleaner.