4

My team recently migrated from ClearCase to Git. Some team members are accustomed to hijacking files, which in ClearCase means making private changes to a tracked file, changes that you don't intend to share with anyone.

ClearCase basically ignores such files when doing the equivalent of a Git add/commit, and won't overwrite them when doing the equivalent of Git pull.

Is there an equivalent in Git?

Note I'm not saying this is a good workflow, even in the ClearCase world. The answer to "why would you want to" is that it's what they're used to.

gatkin
  • 1,902
  • 12
  • 12

2 Answers2

4

The closest approximation of "hijacked" would be a file for which you specify to the git index that it has to be ignored:
(See "Git: untrack a file in local repo only and keep it in the remote repo")

git update-index --assume-unchanged -- afile.

The file is still versioned, but any modification you will do in it won't show up in git status, and won't be committed (and won't be pushed, obviously)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Other possible solution: http://stackoverflow.com/a/13928481/6309 `git update-index --skip-worktree -- aFile` – VonC Sep 25 '13 at 18:03
  • I'll have to investigate both options. It looks like `--assume-unchanged` has the desired effect on `add -u` and `commit -a` but does either that or `--skip-worktree` allow a pull to succeed (skipping the flagged files) so that a push won't be rejected? – gatkin Sep 25 '13 at 18:29
  • @gatkin not sure actually: you have the difference between the two explained here: http://stackoverflow.com/a/13631525/6309. `skip-worktree` seems to resist to a stash (http://stackoverflow.com/questions/18393567/git-hook-for-any-action-that-updates-the-working-directory?lq=1#comment27019296_18393567). – VonC Sep 25 '13 at 18:40
0

You can always make the changes and then not commit them. The changes will "float" around when you pull/merge/commit/checkout; if you try doing something that would overwrite them (e.g., you merge a change that touches the same file), it will refuse - at which point you can git stash your changes, perform the operation, and then git stash (apply|pop) to restore your changes.

If you want these changes actually committed locally but not shared with anyone else, I think your best bet is to maintain them on a local branch that you rebase onto (or keep merged with) the branch the "actual development" takes place on, and just be careful not to actually push the commit(s) that contain the local changes.

ToxicFrog
  • 2,554
  • 18
  • 18