Do you have an example repository to show the issue?
If folks aren't following instructions then it's time to review the
instructions first / as well.
Why not have the master and skeleton branches as being --orphan to each other
(i.e. do not have a common root). This caan help the re-think.
It is also possible that you need to instruct what is 'merging' (for your case)
because this (merging) is not a well understood term - lots of people think
merging means different things depending on their experiences. Git's merge
model is in many ways 'not normal' (because it works ;-)!
It may even be that your excercise (as performed by real users/students) takes
the coding changes beyond what the normal Git easy merging expects.
To make git work well you need small steps, and the students/users need to
learn that (as well)
--
Philip
----- Original Message -----
From: Gregory Mounie
To: Git for human beings
Sent: Wednesday, September 14, 2016 9:36 AM
Subject: [git-users] Best practice for a skeleton/solution code exercise
short story:
I set up an programming exercise with two branches:
- master with the skeleton of the exercise
- solution with the completed skeleton
I would like an "automatic" (simple, enforced) synchronization between both
branches.
long story:
I assumed that the teacher workflow was clear: change the skeleton in master
and merge in solution. (or edit solution branch and cherry-pick in master)
Of course, I was wrong. I had two contributors: one change only master, the
other one change only solution.
Using two repositories, eg. with scripts extracting the skeleton from the
solution repository would have produce worst results, adding difficulties for
post-problem merge.
Using "pull request" instead of direct edition from contributors would have
do the job but increase synchronization burden (for last minute bug fixes)
(Post-commit ? Pre-push ?) script doing merge from master to solution would
solve half of the problem. But how to identify skeleton change in solution to
merge it in master.
Any idea ?
--
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.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
