If you check out a git repository and chmod a checked-in file there
there away from git defaults then "git reset --hard" will re-chmod it.
The use-case for not having this happen is if you e.g. have some
inotify thing or a stat() loop monitoring changes to the files, and
you'd like them to fire on "real" updates, not just updates that were
introduced because something re-chmoded a file.
E.g. on current git.git master:
$ ls -l INSTALL ; chmod 600 INSTALL ; git reset --hard @{u} ; ls -l INSTALL
-rw-r--r-- 1 avar avar 9147 Apr 20 17:11 INSTALL
HEAD is now at e6ac6e1 Fifth batch for post 2.8 cycle
-rw-r--r-- 1 avar avar 9147 Apr 20 17:12 INSTALL
What I'd like is for the permissions not to be altered:
$ ls -l INSTALL ; chmod 600 INSTALL ; git reset --keep @{u} ; ls -l INSTALL
-rw-r--r-- 1 avar avar 9147 Apr 20 17:12 INSTALL
-rw------- 1 avar avar 9147 Apr 20 17:12 INSTALL
But I don't want this to happen:
$ echo "Blah" > INSTALL && git add INSTALL && git commit -m"blah"
[master d29463e] blah
1 file changed, 1 insertion(+), 223 deletions(-)
rewrite INSTALL (100%)
$ ls -l INSTALL ; chmod 600 INSTALL ; git reset --keep @{u} ; ls -l INSTALL
-rw------- 1 avar avar 5 Apr 20 17:14 INSTALL
error: Entry 'INSTALL' not uptodate. Cannot merge.
fatal: Could not reset index file to revision '@{u}'.
-rw------- 1 avar avar 5 Apr 20 17:14 INSTALL
Instead I want:
$ ls -l INSTALL ; chmod 600 INSTALL ; git reset --keep @{u} || git
reset --hard @{u} ; ls -l INSTALL
-rw------- 1 avar avar 5 Apr 20 17:14 INSTALL
error: Entry 'INSTALL' not uptodate. Cannot merge.
fatal: Could not reset index file to revision '@{u}'.
HEAD is now at e6ac6e1 Fifth batch for post 2.8 cycle
-rw-r--r-- 1 avar avar 9147 Apr 20 17:15 INSTALL
And the expectation here is that I'll have something that does a chmod
after the reset happens, which is fine because we had a "real" change,
I just don't want the repo to keep having flip-flopping permissions
because I'd both like:
* Local chmod to be respected
* Actual file content changes to be wiped away by reset --hard
Is there another way to do this, or dare I say alternatively maybe we
could use another option to reset making it even more confusing :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html