CODEWITHSUNDEEP
gitclearcase
gatkin
gatkin

Reputation: 1912

What is the Git equivalent of ClearCase hijack?

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.

Upvotes: 4

Views: 1896

Answers (2)

VonC
VonC

Reputation: 1329092

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)

Upvotes: 4

ToxicFrog
ToxicFrog

Reputation: 2624

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.

Upvotes: 0

Related Questions