1

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.

  • Generally you can do whatever you want on your own branch. Just don't commit changes you don't want in the mainline to the mainline. – user1118321 Jan 27 '17 at 4:03
  • Thanks. When a new commit comes out on the mainline, is it better for me to create a new branch from the new commit to make readability change, or to merge the new commit to my previous own branch with my previous readability change? – Tim Jan 27 '17 at 4:23
  • 2
    I used to work with someone who insisted on moving the code that he was working on to the top of the module. It was a nightmare; nobody could remember where anything was. Before you make changes like that to other projects, consider the possibility that maybe you just need to get better at navigating and understanding other people's code. Related: How do you dive into large code bases? – Robert Harvey Jan 27 '17 at 4:35
  • I think you'll have a very hard time doing either, frankly. I think each will be as hard as the other. – user1118321 Jan 27 '17 at 5:29
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.

  • Rebase can be problematic, so you could also maintain the patch set in its own branch and merge it into your working branch as necessary. But that has its own problems. This shouldn’t be impossible with Git, though; it’s similar to what Linux distro maintainers need to do. – Marnen Laibow-Koser Mar 26 at 3:19
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.