On Fri, Feb 10, 2023 at 03:03:15PM +0100, Uwe Brauer wrote: [...] > > Maybe you would be better off utilizing GitLab for this? [...] > Ah I am not sure. It is not that the students are all working together > on one common project.
This makes no difference - see below. > Basically they have to implement say 8 different methods, and for each I > prepared a repository for them. So the workflow right now is > > 1. The student forks the repository > > 2. The student invites me as a developer (and unprotect his main > branch) and turn email notification for each push on. > > 3. Then to this individual repository I push and pull, and the > student of course as well. > > Are you saying that for such a scenario gitlab's merge/pull request > would be more appropriate and easier to handle? [...] > I have to be honest, I never really tried out pull requests for long, > maybe I am too much of old school, but I am still familiar with sending > and inspection patches, or dealing with pushes of other developers who > have write access to the repository we share. > > Maybe I read too much of this > > https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-requests-and-how-to-fix-them/ I had a cursory glance over the highlighted chunks (the piece is gross, I cannot digest it sensibly over a short period of time, so I have to postpone it until some free time), and the problems the author highlights do indeed exist, but as with any engineering practice, there are existing tools and their trade-offs. I would say, that in your particular case you will simply experience zero problems of those considered by the essay's author: the scale of the prospective requests to be made by your students will simply be not enough to hit them. I posit that merge/pull requests (they are the same thing, modulo some nerdy differences) are merely a device to incorporate changes made by someone to the project's proper. This can be a drive-by contribution or work done by regular developer if the established workflow requires each contribution to go through the review process (I mean, regular devs usually have direct access to their project and could merely apply their changes there directly - rather than jump through the review hoops). So, basically how would one make their changes appear in a project? Historically, you would prepare and send a patch or a patch series to some mailing list; the maintainer(s) would possibly comment on them, maybe you would do several backs-and-forths by reposting the fixed series and receiving new comments on them, and then the series would finally be applied to the peoject's code base. Some high-profile projects still do excactly this - say, Git and the Linux kernel. Later, when "web 2.0" made web UIs be almost on par with those found on desktops of the day, someone had that idea to create a web interface to do a review. I have no idea who was the first (may be Rietveld [3]?), but the general design was simple: you somehow _submit_ your changes to that system, and the project maintainers use the web UI to attach comments to the proposed changes, and you have a way to read them and submit the updates to your changes. You see, the idea is basically the same that that of the e-mail workflow: in the latter a maintainer would quote the text of your mail message containing a patch in their response by mail, and in the former you'd use some UI facility to do the same. Distributed VC systems have trivialized the idea of web-based review because to submit your changes, you would not need anything special: just clone the project, make your changes on a branch, push that branch up, and click some buttons in the web UI. What I'm trying to convey, is that merge/pull requests may sound like a rocket science but in fact they are mere patchsets + an UI to comment on them, nothing more. Say, in GitLab, a merge request is indeed an entity (each MR has a number and has its own "page") but its "beef" is a branch with one or more commits intended to be merged to some other branch. The project maintainers can use the GitLab's web UI to comment on various bits of the proposed changes, and receive responses to their comments. It's all managed by the UI (well, you can receive e-mail notifications and also respond to them, via e-mail). So, that's why I have proposed to consider merge requests: it's merely a device to have a way for you to have targeted conversations with your students on the text (code or whatever) they push without you actually changing that text - because everything you write using the merge request machinery is "meta data": it's stored associated with the textual changes the request contains but not _in_ those changes. Sure, there's no need to rush to switch but I think this worth considering. All-in-all, I, for one, have extensive experience with code review, and using GitLab for doing it, in particular, so you have above average chances to get help on this, when needed ;-) And sure I'm not the only one here who has the same experience. As to particular GitLab's specifics - it does not matter whether each of your students uses a separate repository or a single repository but separate branches, as long as you are granted at least the "developer" access level in these repositories ("maintainer" and "owner" are progressively better, of course). Being "the developer" allows you to open discussions on the merge requests. [...] [3] https://en.wikipedia.org/wiki/Rietveld_(software) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230210154000.43h24kauj4j5etfx%40carbon.
