On Tue, Oct 24, 2023 at 06:38:50PM +0200, Uwe Brauer wrote:
[...]
> Here is the situation. I want to create one single repository that
> contains various (subdirectories). Each subdirectory contains several
> files corresponding to certain sheets my students (numerical analysis)
> have to solve.
>
> The student should clone the repository and then create their corresponding
> solutions in the relevant directories then push, share with me the
> repository etc etc.
>
> However I don't want to push all the directories at once, but during the
> course.
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?
> My first thought was to use .gitignore and just exclude these
> directories.
>
> The problem is I might change some files and want to track these
> changes.
>
> (In mercurial I most likely would use phases, (secret and draft)
> although I am not sure that would really work)
>
> An other option would be to run git init in these directories (but not
> include them as sub-repositories), and hope that git would ignore
> directories that are themselves under git control.
>
> But then I am not sure how I could merge it later to the main
> repository.
Your initial premise is wrong.
In Git (and, I think, any DVCS system) commits are created in individual
repositories and then possibly shared with other repositories - by pushing and
fetching. (Always remember that even though you in your setup have a "central
server" which is a rendez-vouz point to coordinate work on some project,
still, it's just another Git repository, nothing really special.)
A commit is always a snapshot of the whole project managed by a repository so,
by definition, you cannot record such a snapshot and then share only some
parts of it (but not others).
I honestly have no idea how Mercurial manages to do something like that.
As to possible solutions, I think _conceptually_ the simplest one is merges.
I mean, the setup you describe is the very basic workflow routinely used by
some teams: your changes - adding more directories or more files to existing
directories - is merely changes done in some line of development. So, it could
be implemented like that: suppose you have just a single branch; let it be
"master".
1) You start with a single directory, add it, commit then push.
2) Your students clone the repository and end up with their local clones
with their local branch "master" (tracking the same-named branch in the
remote repository named "origin).
3) A student adds their own files, commits then pushes [*].
4) After some time you add more directories, commit then push [**].
5) Your students then do `git pull` to fetch your changes and merge
them into their local "master".
6) GOTO 3.
"The catch" here is bound to happen at points marked by asterisks:
- When a student tries to push while you or some other student has managed to
push their own work since our student has last fetched (or pulled, which is
the same for these matters), the push will fail. The student will then need
to `git pull` and retry their push, which must succeed - unless in the
meantime someone else has again managed to sneak in their changes.
- Your own push may fail by the same reason, and the course of action is
the same: you `git pull` and retry.
The described workflow is often frowned upon as it creates what is called
"diamond history" (because the merges "go in both directions"), but it works.
--
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/20231025084124.ttcwrwljet4z4pho%40carbon.
