On Thu, 23 Jul 2015 11:14:11 +0200
Konrád Lőrinczi klorin...@gmail.com wrote:
[...]
I accept these solutions as workarounds, but the real solution would
be: Dev suggestions:
1) Add a --force-reread option to git status, so user can force
reread tree. git status --force-reread
2) Add
Hi,
On 2015-07-23 09:29, Konrád Lőrinczi wrote:
I wrote a search replace perl script, which recursively searches
files and replaces text in them. After replace, it restores original
modification time (mtime) of file.
Since this is almost identical to
Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov:
On Thu, 23 Jul 2015 11:14:11 +0200
Konrád Lőrinczi klorin...@gmail.com wrote:
[...]
I accept these solutions as workarounds, but the real solution would
be: Dev suggestions:
1) Add a --force-reread option to git status, so user can force
Karsten Blees karsten.bl...@gmail.com writes:
I'd like to add that this is not a git-specific problem: resetting mtime
on purpose will fool lots of programs, including backup software, file
synchronization tools (rsync, xcopy /D), build systems (make), and web
servers / proxies
I wrote a search replace perl script, which recursively searches
files and replaces text in them. After replace, it restores original
modification time (mtime) of file.
Interesting, that git status doesn't show replaced changes, if the
mtime is same as original.
Is there a way to force git
Based on [1] I found some solutions which makes the changed files
appear again as changed:
a) touch -m --date=01/01/1980 .git/index
So it is a touch, but only a single one, instead of touching all the
files in the work dir.
b) git read-tree HEAD
Also working well.
I accept these solutions as
6 matches
Mail list logo
