3

We have an automatically generated javascript file which is tracked in our git repository. The problem is that it includes a (useless) timestamp in a comment, which often creates trivial merge conflicts for us. I'd like to avoid having these conflicts.

I thought I had found a solution with .gitattributes and filter/smudge. I set it up in the following way, so that this timestamp line was stripped from the file upon commit or checkout:

.gitattributes:

<the file>.js filter=tsfilter <the file>.js smudge=tsfilter

.git/config:

[filter "tsfilter"] clean = perl -pe \"s/\\/\\/.*<the pattern>.*$//\" smudge = perl -pe \"s/\\/\\/.*<the pattern>.*$//\"

While this seems to have eliminated merge conflicts, it introduced another annoyance in that this file now remains in a constant state of modification. That is, 'status' stills shows it as modified since the local (pre-filtered) copy includes timestamp line (but the committed file does not).

Is there a better way to go about this which avoids the merge conflicts but also hides local changes to this part of the file?

Improve this question
2
  • 1
    If it's automatically generated, why do you need to track it? Commented Nov 16, 2012 at 23:56
  • It's automatically generated by an eclipse plugin. If this could be done at the command-line then we could perhaps remove it. Commented Nov 18, 2012 at 22:12

2 Answers 2

Reset to default
3

I may be incorrectly interpreting your question, but it sounds like you could make do with either an ours or theirs merge strategy for the file in question. Based on the answer to this question, you could do the following:

.gitattributes:

file.js merge=ours

.git/config:

[merge "ours"] name = Keep my file driver = true

This will always keep your version of the file.

A theirs merge is only slightly more difficult -- you can't just change the driver to false, you need to define a script to keep their changes. The question linked above covers a theirs strategy in more detail.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

While the said line is not important, other parts of the file may have unique contributions from both ours and theirs. Since this file is only generated by developers, the merge needs to retain these differences.
This is also a strategy you could use to regenerate the file. true is really just a shell script, so if you're able to determine a way to run the file generation from the command line, this is one possible implementation method.
1

You could modify the program that produces that file to not include the timestamp, or write a wrapper for the program that would remove the timestamp.

Improve this answer

1 Comment

Unfortunately, that program is an eclipse plugin which we are not currently building ourselves, so I'm not sure this would be easy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.