What Your Take-Home Repo's Git History Shows

When a take-home assignment is delivered as a repository you clone and push back, the reviewer receives more than your final code. They receive every commit object you created, and each one carries two identities, two timestamps, a message with any trailers your tooling appended, and a diff whose size and shape are visible at a glance. This article explains what that metadata contains as of September 2026, which parts are reliable evidence and which are not, and how to handle AI attribution honestly rather than accidentally.

Repository-based take-homes are now a product category

CodeSubmit, one of the platforms that runs take-homes this way, describes the format on its take-home challenges page: candidates "clone the repo, run the app locally, and work with the tools they already know," and submissions come back as "reviewable diffs instead of snapshots." The page states that reviewers examine "commits and code changes your team can discuss, not snapshots detached from the workflow."

That is the design intent, and it is worth taking literally. In a browser-based assessment, the artifact is your final answer. In a repository-based one, the artifact is the history. If you squash everything into a single commit titled "solution," you have removed the signal the format was built to collect — which is itself a thing reviewers notice.

Every commit records two identities and two dates

Git separates the author of a change from the committer who created the commit object, and stores a separate timestamp for each. The git commit documentation exposes both through distinct environment variables — GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE and GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE — and documents the --date flag as one that will "override the author date used in the commit."

To show what this looks like in a submitted repository, we initialized an empty repo, made two commits, and passed --date to the second one. The commands and their real output:

$ git commit --date="2026-09-20T09:00:00" -m "Add tests"
$ git log --format='%h | ad=%ad | cd=%cd' --date=iso
8ffcdf0 | ad=2026-09-20 09:00:00 +0000 | cd=2026-09-29 16:16:40 +0000
c11a614 | ad=2026-09-29 16:16:40 +0000 | cd=2026-09-29 16:16:40 +0000

The author date moved back nine days. The committer date did not. Reading the raw object confirms the two are stored independently:

author    Jordan Candidate <[email protected]> 1789894800 +0000
committer Jordan Candidate <[email protected]> 1790698600 +0000

Most tooling shows the author date by default, so a divergence between the two is not visible unless someone asks for it — and asking for it is one line of git log. Treat both timestamps as readable.

The author email matters for a second reason: it comes from whatever user.email your local git config holds. Candidates regularly submit take-homes authored by their current employer's address, which discloses where they work before they have chosen to.

The trailers your tools append on your behalf

A commit message can carry a Co-authored-by: trailer, which GitHub documents in the format Co-authored-by: name <[email protected]>, placed after a blank line at the end of the message, and renders as an additional author on the commit. The mechanism predates AI tooling — it was built for pair programming — but several AI coding tools now write it automatically.

This has been genuinely unstable, and the dates matter:

• VS Code and GitHub Copilot. The VS Code repository's tracking issue for AI attribution records a version-by-version history: the git.addAICoAuthor setting was introduced in 1.110 defaulting to off, changed to all in 1.117, adjusted to chatAndAgent in 1.118, then reverted. The maintainers wrote that they "reverted the default for the AI attribution feature back to off" in 1.119, and that the feature is also disabled when disableAIFeatures is set. So whether a Copilot trailer appears in your commits depends on which VS Code version you were running this spring.
• Claude Code. Anthropic's Claude Code settings reference documents an attribution setting controlling commit and pull request attribution, superseding a now-deprecated includeCoAuthoredBy boolean.
• Dedicated attribution tooling. The open-source Git AI extension goes further than trailers: its README states that "on commit, Git AI stores line-level attribution data in Git Notes, linking each line of AI-generated code to the agent, model, and session that created it," and that it preserves those attributions across rebases, squashes, and merges.

In our test repository, a trailer written into the first commit message was still readable afterward through git log --format='%(trailers:key=Co-authored-by,valueonly)'. Trailers are part of the commit message; they travel with the commit unless you rewrite the message.

The practical consequence is not that a trailer condemns you. It is that the trailer is a disclosure you may not know you made — or, worse, one you stripped without meaning to. Know which of your tools writes one before you push. If the assignment's instructions permit AI assistance, an accurate trailer is the cheapest possible compliance with them. Our guide to the rules take-home assignments now set for AI use covers how those instructions are typically worded.

Shape signals: cadence and diff size

Beyond metadata, reviewers read the contour of the history. Two commands produce most of it.

git log --shortstat prints insertion and deletion counts per commit. Running it against our test repo:

30a6251 Implement service layer (2026-09-29)
 1 file changed, 400 insertions(+)
8ffcdf0 Add tests (2026-09-20)
 1 file changed, 1 insertion(+)

A 400-line insertion landing in one commit under a generic message is a different-looking artifact than the same 400 lines arriving across a dozen commits with failing intermediate states. Neither proves anything on its own. A senior engineer working from a clear spec legitimately produces large, clean commits; a careful candidate using an agent legitimately produces small ones. But the first pattern invites the follow-up question, and repository-based formats are explicitly designed so a human can ask it.

git log with a time-formatted committer date shows cadence — how work was distributed across the window you were given. A history where every committer timestamp falls inside a ten-second span tells the reviewer the commits were generated in one pass, whatever their author dates claim.

What rewriting history changes, and what it does not

You can rewrite a git history. --amend, interactive rebase, squashing, and filtered replays all work, and there are legitimate reasons to use them — cleaning up a typo, dropping a stray secret, collapsing genuine noise before review.

Two things are worth being clear-eyed about. First, rewriting is incomplete by default: as the demonstration above shows, --date moves only the author date, so a superficially backdated history often leaves committer timestamps that contradict it. Second, and more importantly, a history reconstructed to imply work you did not do in the way you are implying is a misrepresentation of your own work, independent of whether anyone catches it. A reviewer who spots it does not conclude that your git skills are weak; they conclude your submission was a claim about yourself that was not true. That is a far worse outcome than an honest single commit, and worse than most outcomes in our guide to what happens after an assessment raises an integrity flag.

The defensible position is simpler: commit as you actually work, disclose AI assistance if the instructions ask for it or permit it, and be prepared to explain any part of the diff out loud.

Files you ship that are not code

A repository also carries whatever you left in the working tree. Agent and editor configuration — .claude/, CLAUDE.md, .cursor/, .aider*, .vscode/, .idea/ — frequently gets committed by a git add -A at the end of a session, as do local .env files, scratch notes, and prompt logs. This is an inference from how these tools lay out their files rather than a documented platform behavior, but it is easy to check and easy to fix: run git status and read your own diff before the final push, exactly as you would in a code review.

The same discipline protects you in the other direction. A cloned take-home repository is executable code from a stranger, and repositories distributed as fake assignments have been used to deliver malware through install hooks; our write-up on how to inspect a take-home repository before running it covers what to check first.

Where a live interview assistant fits, and where it does not

Control is a desktop AI assistant built for live interviews, assessments, and screen-share workflows: real-time transcription, screenshot capture of the problem in front of you, hotkey-triggered answers in an overlay the homepage describes as "screen-share invisible," on Windows and macOS. It is designed for the pressure of a synchronous session where you cannot stop and think.

An asynchronous take-home is a different problem, and it is worth saying plainly that this product category does not solve it. You have hours or days, your own machine, and no interviewer watching. What determines the outcome is the quality of the code, the honesty of the history, and whether you can defend the work in the follow-up conversation — which is usually where the real evaluation happens. If that follow-up is a live review call, our guide to what AI-assisted coding interviews actually grade is the more useful preparation.

The short version

Before you push a take-home repository: check git config user.email, run git log --format='%h %an %ad %cd' --date=iso to see both timestamps, run git log --shortstat to see what your diff shape says, check whether your editor or agent is writing Co-authored-by: trailers, and read git status for files you did not mean to ship. Then decide, deliberately rather than by accident, what your history discloses.

If the round that follows is a live, screen-shared review, Control runs on Windows and macOS and starts with a free allowance of 5 messages and 2 minutes of voice, no card required (see pricing); you can download it and test it against a practice session before it matters.