On Wed, Oct 25, 2023 at 02:15:43PM +0200, Uwe Brauer wrote: >> Do you mean the repository has to begin with zero or, say, one such >> subdirectory, and others have to appear there picemeal - as you add them? > > Right, and I think I explained my workflow poorly. So let me start > again. > > Last year I had for one sheet, one directory (actually the directory > contained a PDF, a .m and a .mlx template file: BTW bad idea to use mlx, > it is zipped xml and git and other VC cannot really deal with them: diff > and blame do not really work). > > So when I was finished preparing one directory, > - I pushed it to gitlab, > - shared it with the students, > - they had to fork it and then share their forks with me. > - There was pushing, pulling, merging, editing conflicts etc, but more > or a less it was a smooth experience. > > However this year I will have 50 students and 8 sheets, which would > result in 400 repository, clearly an overkill. > > So I thought to work with only one directory/repository that contains 8 > subdirectories. > > Now I don't want to push all 8 subdirectories in one go, because the > students should work sequentially. So I see two options > > 1. I will have the sheets in my repository, and when it is the > moment, I copy the directory to the one I share with my students > add the files commit and then push to gitlab > > 2. Instead of copying I have already all files in the corresponding > subdirectories, but they are not pushed because I have configured > .gitignore that way. The problem is then: if I change something in > these directories these changes are not tracked; I could try git > init in each subdirectory, but it seems another maybe unnecessary > complication. > > In any case one thing is not clear to me, and it maybe concerns more > gitlab than git itself: [... I cut one piece from here to reply to it separately - see below ...] > Did I explain this now better?
Well, the expanded explanation is exactly how I imagined it after reading your initial mail, so I basically have nothing to add except minor clarifications. The first and major thing worth reiterating is that when Git repositories communicate - when you do push (send, share) or fetch (receive) - they always exchange commits (I would like to write "complete commits" but there's no such things as incomplete commits). A commit refers to (points at) its parent commit (or commits) and exactly one "tree" which represents the contents of the top-level directory of the repository. That tree refers to blobs representing files in it and other trees - representing subdirectories (and so on, and so forth - recursively). That way, any commit always is a complete snapshot of the whole project. And as such you cannot push (share) only some parts of it: Git sends and receives whole, complete commits. So, if you'd like to "keep aside" certain changes for certain time, you cannot record them in a commit and then not send them when you send (share) that commit. Given that, there are two ways to make the changes available, and they are basically the same: - Just keep them outside of Git's control - that is, do not commit them until there's time for them to get shared. - Commit them, but do that on a separate branch. Whet it's time, you merge that branch into the one used to share these changes, then push. This one won't work with a single separate branch if you have more than a single directory to make available in turn. I mean, if you have, say, 10 such directories, and would like to put them under the Git's control all at once - if only for "backup" purposes, - but publish one after another, you would need 10 separate branches - one per separate directory, which you would then merge one after another into the main branch. > If after one week I push again to my gitlab repository > (pushing the new subdirectory), > > 1. how will the students notice that in their forks? Automatically? They won't in the sense they won't receive any automatically generated e-mail message or something like this. Manually - they will: if one performs `git fetch` and then runs `git status`, the latter will tell something like "Your branch is N commits behing the branch it tracks". > 2. Do they have to pull or, horror, make another fork? They will have to pull - that is, fetch then merge (that's what pull does), and that's exactly what I proposed. In other words, to me, this model does not differ from the most usual application of Git where Joe, Jill and Mary work on a single project: when Joe commits, Jill and Mary usually want to make those changes available in their respective local repositories, so they fetch and merge (pull) or fetch then rebase (but let's not touch this one). -- 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/20231025133839.d47whaxutx5mhhom%40carbon.
