top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Git reset should be able to ignore file permissions

+1 vote

Recently I had to write some automation scripts and I found that git reset --hard actually restores each file's permissions.

That is causing both the created and the last-modified dates of the file to get changed to the time of the git reset.

This behavior is easy to demonstrate:

echo "test" > myfile
chmod 777 myfile

git add myfile && git commit -m "Test" & the only solution I'm able to think about is actually restoring the permissions of each file to the ones git thinks they should have before doing the git reset.

Maybe I'm wrong and there is a way for doing what I want, if so, please correct me. But if there isn't, should this be implemented? Are there any reasons for not doing it?

posted Jun 18, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote
> echo "test" > myfile
> chmod 777 myfile
> git add myfile && git commit -m "Test" && git push
> chmod 775 myfile
> git reset --hard origin/master

This doesn't tell what the permissions are in origin/master.

If the last line was "git reset --hard HEAD", then it wouldn't touch myfile (it's executable in the worktree and in HEAD, so Git doesn't need to change it). Neither the x bit, nor the ctime or mtime.

If you reset the file to a point where it was not executable, then Git changes its executable bit, and I don't see why it would do otherwise:
Git tracks the executable bit, so when you say "reset the file to how it was in this revision", this includes the content and executability.

Reading your message, I don't understand why you need to be able to ignore the x bit.

answer Jun 18, 2013 by anonymous
+1 vote

Git does preserve file permissions, that is, git is aware of the permissions you can set with chmod.

I'm not trying to ignore the x bit, what I'm trying to do is make "git reset" checkout only the files that actually changed instead of checking out all the files with different permissions than the ones git thinks they should have.

Said with other word: when you run "git reset", git does a "status" and checkouts all the files that showed up from the "status". That's exactly what I'm trying to avoid, as "status" is aware of both content changes and permissions changes.

answer Jun 18, 2013 by anonymous
Similar Questions
+1 vote

How can I make git ignore the time stamp(s) in a PDF. Two PDFs that
differ only in these time stamps should be considered identical.

Here is an example:
| > pdfinfo some.pdf
| Title: R Graphics Output
| Creator: R
| Producer: R 2.15.1
| CreationDate: Thu Jan 24 13:43:31 2013 "$TMPFILE"
| ## update the pdf metadata
| pdftk "$FILENAME" update_info "$TMPFILE" output "$TMPFILE2"
| ## overwrite the original pdf
| mv -f "$TMPFILE2" "$FILENAME"
| ## clean up
| rm -f "$TMPFILE"
| rm -f "$TMPFILE2"
| if [ -n $FILEASARG ] ; then
| cat "$FILENAME"
| fi

This 'works' as far as the committed pdf indeed has the date reset to my default value.

However, when I re-checkout the files, they are marked modified by git.

So, my question is: How can I make git *completely* ignore the embedded date in the PDF?

0 votes

I have a disk image of a small embedded device whose root file system I'd like to check-in to git as a means of distributing its GPL'd software. In that disk image are device files, which GIT studiously ignores. If symlinks are handled (contents being the path that the symlink points at), I don't see why device files can't be handled (contents being the type (char or block) and the major and minor device number). TAR, for example, handles this fine, except that using tar in git sort-of goes against the granularity of the objects being modified (like adding a bunch of extra "sd??" devices), such that you are modifying a whole tar ball instead of the individual (device) files.

Is there a reason not to handle device files other than "its not traditional"? That's the only reason given in google or the IRC channel.

+1 vote

I created a repo on a server, and followed instructions to make a new git group, and assign users to the group .. then I set it so the shell is git shell, and the users can only access the files through git .. this is great .. now, can I create a user that can only pull?

+1 vote

If I have a git repository with a clean working tree, and I delete the index, then I can use git reset (with no arguments) to recreate it. However, when I do recreate it, it doesn't come back the same. I have not analyzed this in detail, but the effect is that commands like git status take much longer because they must read objects out of a pack file.

In other words, the index seems to not realize that the index (or at least most of it) represents the same state as HEAD. If I do git reset --hard, the index is restored to the original state (it's byte-for-byte identical), and the pack file is no longer read.

Before I try to dig in to why this should be so, does anyone happen to know off the top of their head? Does this constitute a bug in git, or a bug in my understanding of git?

0 votes

I have my global git config pager set to 'cat', but when I do a "git help ", it still uses a pager. This is especially irksome in emacs shell buffers, where I am most of the time. I know I can do a M-x man -> git-, but wondered if this was a bug or user error. ("git --no-pager help " does the same.)

% git --no-pager help log
WARNING: terminal is not fully functional
(press RETURN)