The GitHub Repository

git shortlog is the command that answers it, and it is what GitHub's contributors list is built from:

$ rm -rf ~/who-wrote-it; mkdir ~/who-wrote-it && cd ~/who-wrote-it
$ git init -q
$ git -c user.name="Aditi Kulkarni" -c user.email="aditi@college.example" \
    commit -q --allow-empty -m "Add the README"
$ git -c user.name="Farhan Shaikh" -c user.email="farhan@college.example" \
    commit -q --allow-empty -m "Take an order's stock in one update"
$ git -c user.name="Sneha Patil" -c user.email="sneha@college.example" \
    commit -q --allow-empty -m "Draw the counter's list"
$ git -c user.name="Rohan Deshmukh" -c user.email="rohan@college.example" \
    commit -q --allow-empty -m "Limit failed sign-ins"
$ git -c user.name="Farhan Shaikh" -c user.email="farhan@college.example" \
    commit -q --allow-empty -m "Give back a cancelled order's stock"
$ git --no-pager shortlog -sne HEAD
     2	Farhan Shaikh <farhan@college.example>
     1	Aditi Kulkarni <aditi@college.example>
     1	Rohan Deshmukh <rohan@college.example>
     1	Sneha Patil <sneha@college.example>

Two things to read in that answer: every author is a person, with a college address, and the counts are not one person's project with three names attached. Run it on your own repository in week 13, and if a name is wrong, fix the setting on that machine and say so; a wrong name cannot be corrected in the history without rewriting it, which is worse.

Say HEAD, as that command does. With nothing to count, git shortlog reads its standard input, expecting git log's output to be piped in, and in a script or anywhere without a terminal it therefore prints nothing at all and looks like a repository with no authors. It was written here without HEAD first, and that is exactly what it did.

Nothing in it that should not be there

This is the part that costs marks, and occasionally more than marks:

Three commands to run before you submit, on your own repository:

git ls-files | grep -Ei '(^|/)\.env$|\.jks$|\.keystore$|^node_modules/'
git log --all --diff-filter=A --name-only --format= | sort -u | grep -Ei 'secret|password|\.env|key'
git count-objects -vH | grep size-pack

The first lists forbidden files that are tracked now; the second lists every file ever added in the history, which is where a secret committed in week 3 and deleted in week 4 still lives; the third says how large the repository is, and a size in tens of megabytes usually means node_modules or a build folder went in at some point.

If a password was ever committed, change the password. Deleting the file does not remove it from the history, and rewriting history on a shared repository breaks everybody's clone. Changing the secret is the only fix that works, and saying so in the report's limitations is better than hoping.

Making it openable by the examiner

A repository the examiner cannot open counts for nothing, and this is a decision, not an accident. The worked repository was private all semester, with the four members as collaborators, which is the right default for student work. Before the examination the team had three choices:

Ask your guide which the college wants, in week 13, with the other submission questions (Chapter 70). Whatever you choose, put the repository's address in the report, on the certificate page or the first page, where it cannot be missed.

The release, and what the tag is for

Chapter 62 tagged the submitted version v1.0 and published it as a release with the APK attached. Two reasons that is worth the five minutes:

• The report describes one version, and the tag names it. Without a tag, "the submitted code" is whatever main happens to be when the examiner looks, which may be three commits later.
• The examiner can download the app that was demonstrated, rather than trusting that the APK on your phone came from this code.

The repository review, before you submit

Do this for your project

1. Create the repository in week 1, private, with the whole team as collaborators.
2. Set user.name and user.email on every machine before the first commit.
3. Commit as you work, in small commits that name what changed; never git add ..
4. Keep .gitignore honest from the first day; .env and keys never go in.
5. Use branches and pull requests, so the history shows that code was read.
6. Track defects as issues and close them with the commit that fixes them.
7. Run the ten-line review above before you submit, and the three forbidden-file commands with it.
8. Tag the submitted version, publish a release, attach the APK, and put the address in the report.

Mistakes that cost marks

One member committing everything, because the others sent their files by chat.

Two hundred commits on one day, all named "update".

git add ., which is how .env, a keystore and somebody's photographs get committed.

node_modules/ in the repository, which makes it enormous and says the team did not know what a lock file is for.

A private repository with no way in, discovered on the examination day.

No tag, so nobody can say which commit the report describes.

A README that does not work, which undoes the good impression of everything else.

Quick revision

• An examiner reads, in order: README, file list, history, contributors, issues, pull requests, releases.
• The history shows how many people, over how long, and whether tests came with the code; it cannot be arranged at the end.
• git shortlog -sne HEAD is the contributors list: every member, real name, college address (git config, Chapter 39); without HEAD it reads standard input and prints nothing.
• Never committed: .env, keys and keystores, node_modules/, build output, real people's data, secrets in code.
• A secret ever committed means change the secret; deleting the file is not a fix.
• Decide how the examiner opens it, and put the address in the report.
• Tag the submitted commit, publish a release, attach the APK.

Questions you must be able to answer

1. Why is the repository assessed and not just the code inside it? Because it is the only deliverable that can be inspected without the team present, and because how the work was done is part of what is being taught: the history shows who built what, over what period, and whether code was read and defects tracked.

2. What can an examiner tell from a commit history without reading a single diff? How many people worked, over how many weeks, in which parts of the system, whether tests arrived with the code they test, and whether the work was continuous or done in one burst at the end.

3. Why must every machine set user.name and user.email before the first commit? Because those two values are recorded in every commit and are what the contributors list is counted from. A member who never set them appears under whatever their computer's account is called, or not as themselves at all, and the history cannot be corrected afterwards without rewriting it.

4. What must never be in the repository, and what do you do if a password was committed? Settings files with real passwords, signing keys and keystores, installed packages, build output, real people's data, and secrets pasted into code. If a password was ever committed, change the password: it remains in the history even after the file is deleted, and rewriting a shared history breaks every clone.

5. Why tag the submitted version? So that the report, the demonstration and the code can be shown to be the same thing. Without a tag, "the submitted code" is whatever the main branch holds when somebody looks.

6. How should the examiner get access to a private student repository? By a decision made in advance with the guide: make it public after checking that no secret was ever committed, or add the examiner as a collaborator, and either way print its address in the report. Leaving it private with no arrangement is the same as having no repository.