17

Background:

We have generated files in our system that need to be committed in their final state (e.g. we can't rely the source (ungenerated) files and make the generated ones on the fly). Since we need the generated files, those files cannot be git ignored.

Problem:

The files trigger a lot of Your local changes to the following files would be overwritten by merge errors from git on checkout and pull commands.

When I pull or checkout, I never care what my files were, I only care about the new files. (Obviously I care a lot about the source file that makes the generated files. I'm happy for merge warnings on the source file, which is kept in a different directory.)

However, when I commit, I want my version to "win" and my generated files to be committed.

Possible solution:

Right now I just run git checkout -- generated-files/ before a pull or checkout to reset my generated files and skip any merge errors. It works, but I often forget to do it, and I'd like to automate it if possible.

I looked into a pre-checkout and pre-pull hook, but git doesn't provide them :(

Questions:

  • Is there a better way to deal with generated files?
  • Is there a way to force the git checkout -- generated-files/ to run before a pull or checkout?
  • How do you deal with generated files in git?
Lucy Bain
  • 2,496
  • 7
  • 30
  • 45
  • what about doing a `git stash`, then doing a pull, followed by a `pop`. it would keep your changes. – BatScream Dec 23 '15 at 06:04
  • if both branches have caused change to a generated file, keeping either of braches would be not correct. You should perform the generation after resolving conflicts in other files and then record the result as merged version – max630 Dec 26 '15 at 16:50

2 Answers2

11

My personal mantra: if the file can be generated, only the parts that can generate it belong under source control. Otherwise, you wind up with a lot of the noise that you're encountering right now.

If the generated files are a genuine, recurring, repeatable step and part of your build chain, it is safe to add the directory they live under to your .gitignore file (and don't forget to git rm --cached the folder so they're not tracked anymore).

If the generated files are part of the actual source code, then a conversation should happen between members of the team and/or leads, and discuss why these files are under revision if their generation is automated. There may be legitimate reason to keep tabs on them, and there may not be - it's worth the ask, at least.

My recommendation is to ignore any files that were generated and keep them out of Git. But, you'll want to talk to your teammates to see if that's the convention everyone wants to adhere to.

Makoto
  • 104,088
  • 27
  • 192
  • 230
  • 3
    once I had to commit generated files because generating them would require software I could not install to all target systems. I did it, but added there checksums of original files. Then, if anybody was changing original files without updating generated files it would cause buil error – max630 Dec 26 '15 at 16:54
  • 4
    Back in the real world, this aint always possible. For lots of bad reasons. – Tuntable Mar 26 '17 at 23:42
  • 2
    Does adding `generated-file -merge -diff` to `.gitattributes` help, so you can at least avoid getting merge conflicts in those files? – Hjulle Nov 02 '20 at 17:23
-2

A comment for accepted answer:

This default assignment may cause DoS due to globbing. Quote it. Problematic code:

: ${COLUMNS:=80}

Correct code:

: "${COLUMNS:=80}"

Reference: https://github.com/koalaman/shellcheck/wiki/SC2223

Vitalii Ivanov
  • 19
  • 3