4

Use case: we have some project meta-data files which we want tracked, but are rarely (if ever) committed, though they are locally updated all the time (different users have different project paths). In regular scenarios, no user should ever commit these files unless explicitly required.

Git ignore is used for untracked files.

Is there a similar function for git to ignore tracked files? Is there a said method that I can change in the central repo, and will reflect on all users?

Yuval Adam
  • 161,610
  • 92
  • 305
  • 395
  • possible duplicate of [git: ignoring a file which *is* version controlled](http://stackoverflow.com/questions/5011390/git-ignoring-a-file-which-is-version-controlled) – P Shved May 08 '11 at 10:38
  • I guess, this question is a winner of Git Duplicates SO Competition. – P Shved May 08 '11 at 10:39
  • 1
    @Pavel: except none of those duplicates mention the actual solution in the OP's context, which is a filter driver. See my answer below. – VonC May 08 '11 at 10:49
  • @VonC, well, one of them does contain, [the one you linked](http://stackoverflow.com/questions/2965060/gitignore-doesnt-ignore-files). – P Shved May 08 '11 at 11:04
  • @Pavel: except the one I linked (and wrote) doesn't mention the exact steps those scripts must take in the OP's context, that is to decide if the *content needs to be committed or not*. Plus, I was commenting about the duplicates *you* were referring to. – VonC May 08 '11 at 11:07
  • @VonC, ok, thank you for making yet another duplicate. Different contexts, same gist, in all of these... – P Shved May 08 '11 at 11:12

3 Answers3

3
$ git update-index --assume-unchanged <filename>

This only works locally, though.

Carl-Eric Menzel
  • 1,246
  • 7
  • 18
3

Is there a said method that I can change in the central repo, and will reflect on all users?

No in a general (distributed) context: no hook or process of any kind can be "changed" on a central location and picked by all distributed downstream repos.

If your user created their repo following a central template, then some default hook could reference a central script (i.e. a script accessible by all users in a shared disk, if we are speaking on users on the same network).

adymitruk's answer argues to use a development branch, hence not committing private changes to "public" branch (i.e. branch that is pushed/pulled).
That is well and good but:

  • this isn't an automatic process (enforceable to all repos), but an action taken by each developer individually (or not taken because they forgot)
  • this involves sorting out the commits you don't want to publish from the ones you need to publish, which you would do in any case with a development branch, except in this case the developer has to do the extra step of remembering that any changes to those particular files must not be merged to the public branch. Ever. (provided he/she actually took the time to isolate those particular changes in a separate commit!)

It would be better to use a filter driver (which is declared in a .gitattributes file and can be propagated through clone) with:

enter image description here

  • a smudge script:

    • able to recognize the content of your meta-data files
    • saving their content on a checkout

  • a clean script:

    • able to recognize the content of your meta-data files
    • decide if their modifications need to be committed or not
    • restore the initial content of those meta-data files on commit
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

Use development branches. Commit your specific change for your environment. Back merge with ours strategy. Now those changes will never be shared to the public branch. The other answers are missing the point of using development branches.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Good point: we were missing "development branch": +1. But that doesn't address the OP's specific need, which is to enforce somehow on all repos the non-modification of those files. -1. I have included your answer, with comments, in mine. – VonC May 09 '11 at 05:31
  • True. Like @VonC mentioned this isn't really the question in hand, but relevant nonetheless. Thanks. – Yuval Adam May 09 '11 at 09:39