Re: GSoC-2020 update: Jul 31

[Jean Abou Samra]

   Hi Owen,

     Le 6 août 2020 à 03:19, Owen Lamb <owendlamb@gmail.com> a écrit :

   Wow!
   Thanks everyone... even if a lot of this went over my head. I've never
   rebased before, so I can't say what would be the better option.

   There are many tutorials on the Web about this, for instance

   [1]https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd7
   7c#:~:text=git%20—%20Rebase%20vs%20Merge.%20Rebasing%20and%20merging,fr
   om%20the%20last%20commit%20of%20the%20master%20branch%3A

   At any rate, my understanding is that I'll organize my commits near the
   end of the project to make sure everything is reviewable, correct?

   Yes, you will squash certain commits (concatenate them into a single
   commit) so that reviewers find a logical progression in your work. It
   is also critical that, even if the intermediate commits do not contain
   the whole feature, they must compile and give a usable LilyPond. This
   is for bisecting bugs. (It’s mentioned somewhere in the Contributor’s
   Guide, I can’t find the link...) Sometimes, this even means squashing
   all of your commits together.

   If that's the case, it might just be good to wait until then before I
   rebase and/or merge anything.

   Indeed, that’s what Jonas meant. The only caveat is that if master
   changes too much in the meantime in the same area, conflicts will be
   harder to solve. That said, I don’t think this particular area is
   evolving fast, is it? So, in the end... do it the way you prefer.

   Best,
   Jean

References

   1. 
https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd77c#:~:text=git
 — Rebase vs Merge. Rebasing and merging,from the last commit of the master 
branch: