>>> "KK" == Konstantin Khomoutov <kos...@bswap.ru> writes:
> On Thu, Feb 09, 2023 at 11:10:48PM +0100, Uwe Brauer wrote:
> [...]
>> Right now I am most worried about the situation in which the student
>> need to perform a merge. I regularly pull from their repos, check, write
>> my comments and push as soon as possible. Some day they want to push but
>> I have already pushed (the most standard situation in a server based
>> model, but, I have to see how well git pull [1]
>> will deal with this situation (I cross my finger that no conflicting
>> editing appears)
> It's interesting that what you describe looks like the so-called "(merge/pull
> request review" I, for one, routinely do each day.
> Maybe you would be better off utilizing GitLab for this?
> Basically, you ask your students to push to their own branch and create what
> GitLab calls a "merge request" out the changes they have pushed.
> You then use the GitLab web interface to open so-called discussions which can
> be attached to specific ranges in the changes participaing in the MR.
> A student is then supposed to push a fix and and a comment to each discussion
> opened which can then either be continued or closed.
Ah I am not sure. It is not that the students are all working together
on one common project.
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? If so I might give it
some thought, but for next year.
This year they had quite enough with configuring their
1. Configuring their user name, email, for each repository locally
because of the one user for each PC,
2. invite me, unprotect the main branch,
3. turning the credential helper off,
4. turn on email notification.
> It's not necessary to actually merge the MR if this is not needed: it can be
> closed and its branch deleted.
> GitLab makes opening MR's easy: when you push to a new branch, Git run by
> GitLab literally offers you a link to use to create an MR out what you've just
> pushed. But it can be done using specific actions from the GitLab UI.
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/
> This way, there will literally be no possibility for races and no need to
> merge anything.
> GitLab will also send e-mail notifications both to the MR's author when you
> open/clone the discussions in it, and to you when someone comments on these
> discussions.
> [...]
>> [1] «fun fact»: «git pull» is in mercurial «hg fetch», while «git fetch» is
>> in
>> mercurial «hg pull -u». Both system seem in many points being sort of
>> orthogonal to each other. Anyway that is a different story.
> Well, there's just a limited set of verbs to use for these actions, and I
> think what was ended up picked by each of the project is rather arbitrary.
Well that is true, but for example
git log --graph
shows you the branch you checked out, if you want to see all branches use
git log --graph --all
While in mercurial it is the other way around
hg log --graph
Shows all branches, if you want a specific one it is, for example
hg log --graph -b default
> By the way, I'm in a camp which is opposed to ever touching pull in Git: to
> me, it has too much magic built in. I think it's better to use `git fetch`
> followed by explicit inspection of what are the differences of what you have
> locally and what you have fetched, followed by the conscious merge or rebase.
> A good testimony for this approach is given in [2].
I completely agree: for the repositories I use (either with mercurial itself
or with the hg-git plugin),
I first run
hg pull -u
and then I do the merge myself
(On the other hand I told to some of my collaborators, not for software
projects, to
use hg fetch and trust its merge properties)
only once in a while I run really
git pull
basically when I am afraid I the merge process in git would need more
specific git knowledge I currently have, but most likely this is
unfounded, and I am just lazy 😉
> [2] https://longair.net/blog/2009/04/16/git-fetch-and-merge/
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
--
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/87edqx39ek.fsf%40mat.ucm.es.
smime.p7s
Description: S/MIME cryptographic signature
