Brent, who had started at JavaChip in QA several years ago, was tapped for “real” work with the core development team. On the day of his transfer, he gathered his things from his desk in a cardboard box, told his teammates in QA that he’d continue to see them for D&D at lunch, and trekked down the hall to the larger office.

After finding his new desk, he went to find Karla, his team lead. As it turned out, Karla had called in sick, but she had sent Brent an email from home. Get settled in, she wrote. Our repo’s on the company git server. Make sure you have Maven and IntelliJ installed on your machine. Everything else is in the README.md file.

The home page of gitignore.io

Dutifully, Brent pulled down the repo. The size counter crept up. 10 MB … 20 … 30 …

He had just pulled a 100MB repository onto his computer.

Log Jam

There was no conceivable way the repo should be that large.

First, he imported the project into IntelliJ and built it with Maven, making sure there wasn’t anything wrong before he started tinkering. With no compiler errors or warnings, he opened WinDirStat and pointed it to the repo. The code relied on some hefty third-party libraries, but an initial scan revealed that those libraries didn’t take up more than 10MB. Including company-owned code, he had accounted for about 15MB of the 100MB repository size.

Brent saw the bigger issue. In chrome red, faceted so small each file was about a pixel in size, were over 85MB of log files. They were generated by Maven and other parts of their compiler chain, written each time the project was built.

Well, this should be easy, Brent thought. I’ll just add the log directories to .gitignore. Not bad for my first day on the team.

Brent opened IntelliJ and dug around for a .gitignore file. Only there wasn’t one. He checked the root directory, in /src and other code directories, even a few libraries to make sure it hadn’t been put somewhere unusual. He even made sure IntelliJ wasn’t hiding “system” files, which .gitignore was sometimes treated as. There simply wasn’t one in the repo at all.

Fair enough, he thought. I’ll just write one. Brent added a new .gitignore file in the root, put the log directories (and a few other suspect paths) into it, and submitted his first code change.

A Sick Day Ruined

Brent was feeling confident after his commit. He began rummaging through the repository, getting a feel for the codebase.

However, sometime after lunch, Brent heard phlegmatic coughing from the entrance. Karla, the team lead, had come in on her sick day, and she was heading straight for Brent’s desk.

“Brent, cough, we really need you to revert that commit.”

“Why? I just added a .gitignore file.”

“Right, that’s the problem. None of us here ever check in the .gitignore file.”

“Don’t you want to configure your repo properly?”

“We’re all pretty new to git, to be honest, but we had a big mess with conflicts when people were adding their own entries to the gitignore. Just revert and I’ll take care of it.”

Reluctantly, Brent reverted his change.

Ignore() Isn’t Recursive

An hour later, he received an auto-generated email from the company git server: Karla had checked in a commit to the repo. The only change was to add a .gitignore file in the root directory. Thinking that she just preferred to write one herself, Brent opened the file in IntelliJ:

# Exclude gitignore from git
.gitignore

Brent checked the email again. The commit message was prevents .gitignore from being added to the repo. Karla had tried to get the repo to ignore .gitignore … using .gitignore. But for the rule to work, .gitignore needed to be added to the repo. Worse, Karla told him to keep his hands off the file, meaning nothing else could ever be ignored on the repository other than that file.

For the remainder of his first day on core team, Brent’s head spun. On QA, he sometimes wondered how things worked on the core team. But sometimes it’s not worth knowing how the sausage is .gitignore-ed.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!