Asked  6 Months ago    Answers:  5   Viewed   22 times

Every developer on my team has their own local configuration. That configuration information is stored in a file called devtargets.rb which is used in our rake build tasks. I don't want developers to clobber each other's devtargets file, though.

My first thought was to put that file in the .gitignore list so that it is not committed to git.

Then I started wondering: is it possible to commit the file, but ignore changes to the file? So, I would commit a default version of the file and then when a developer changes it on their local machine, git would ignore the changes and it wouldn't show up in the list of changed files when you do a git status or git commit.

Is that possible? It would certainly be a nice feature...



Sure, I do exactly this from time to time using

git update-index --assume-unchanged [<file> ...]

To undo and start tracking again (if you forgot what files were untracked, see this question):

git update-index --no-assume-unchanged [<file> ...]

Relevant documentation:

When this flag is specified, the object names recorded for the paths are not updated. Instead, this option sets/unsets the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.

Fail gracefully in this case means, if there are any changes upstream to that file (legitimate changes, etc.) when you do a pull, it will say:

$ git pull
   72a914a..106a261  master     -> origin/master
Updating 72a914a..106a261
error: Your local changes to the following files would be overwritten by merge:

and will refuse to merge.

At that point, you can overcome this by either reverting your local changes, here’s one way:

 $ git checkout filename.ext

then pull again and re-modify your local file, or could set –no-assume-unchanged and you can do normal stash and merge, etc. at that point.

Tuesday, June 1, 2021
answered 6 Months ago

No you cannot force a file that is already committed in the repo to be removed just because it is added to the .gitignore

You have to git rm --cached to remove the files that you don't want in the repo. ( --cached since you probably want to keep the local copy but remove from the repo. ) So if you want to remove all the exe's from your repo do

git rm --cached /*.exe

(Note that the asterisk * is quoted from the shell - this lets git, and not the shell, expand the pathnames of files and subdirectories)

Tuesday, June 1, 2021
answered 6 Months ago

You can read the file only if the program that opened the file first specified read sharing rights on that file.

If the file does indeed have no read sharing rights though, you wouldn't be able to copy it in the first place.

You may not be able to access a file if you are specifying a sharing right that conflicts with the sharing right of a program that already has the file opened. For example you can't grant write access if the program that already has it opened isn't granting write access.

If the program that opened the file in the first place supports Volume Shadow Copy (VSS), you can also use VSS to gain access to the file.

There are commercial software drivers that allow you to access such files, even when they are in use. You used to be able to get Open File Manager by St-Bernards, and you can also use File Access Manager (FAM) by VisionWorks Solutions Inc. These drivers are typically OEM'ed to backup software companies for inclusion in their products.

VSS works by telling the program that has the file opened already that another program would like to read from the file. VSS then does a copy of the file and lets you read from this copy. VSS does not work for legacy applications.

FAM transparently works for legacy and non-legacy programs alike by specifying an 'allowed list' of applications that can access exclusively opened and locked files. Only programs in this list are allowed access to these files. When a file is being opened, it goes into cache mode so that you will obtain a copy of the file as it was when the 'backup/open' of the file started. At this point the program that originally opened the file sees the file as it actually is, and the second program in the allowed list, sees the file as it was when the 'open/backup' of the file happened. This ensures consistency of the file.

Monday, June 14, 2021
answered 6 Months ago

Try My FolderName/Web.config or "My FolderName/Web.config"

Sunday, August 1, 2021
answered 4 Months ago

First, try making a files subdirectory in your wiki, and putting your files in there.

I tried using an html anchor tag

<a href="files/file.csv" download="file.csv">download this</a>

instead of the markdown link syntax

[download this](files/file.csv)

but it seems that GitHub wiki strips out the download attribute from the anchor tag.

In the end, I zipped my spreadsheet in a zip file and had the markdown link point to the zip file.

[download this](files/
Thursday, August 5, 2021
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :