From: Marc Strapetz <hidden> Date: 2016-06-15 22:50:19
I'm looking for an unobtrusive way to apply (committed) changes for
text/eol attributes to the working tree. For instance, after having
changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
converted from CRLF to LF endings. The only advice I found so far is to
remove .git/index and do a reset --hard. The disadvantage of this
approach is that every file will be touched:
- although the content does not change, timestamps will be changed. This
makes tools like IDEs assume that the file content has been changed.
(Even if the timestamps would be properly reset, the replacement of the
files would have triggered system file change notifications and I'd
expect various tools to still reload these files)
- there will be warnings for files which are locked by other processes
(at least on Windows). I'm usually seeing this for JAR files which are
not affected by eol-attribute changes at all.
One solution I could think of which might be helpful in other situations
as well would be to have an "--unobtrusive" option for reset which would
only replace a file if the content has actually been changed.
Marc.
From: Marc Strapetz <hidden> Date: 2016-06-15 22:50:22
Any ideas on this?
Thanks,
Marc.
On 03.01.2011 18:18, Marc Strapetz wrote:
I'm looking for an unobtrusive way to apply (committed) changes for
text/eol attributes to the working tree. For instance, after having
changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
converted from CRLF to LF endings. The only advice I found so far is to
remove .git/index and do a reset --hard. The disadvantage of this
approach is that every file will be touched:
- although the content does not change, timestamps will be changed. This
makes tools like IDEs assume that the file content has been changed.
(Even if the timestamps would be properly reset, the replacement of the
files would have triggered system file change notifications and I'd
expect various tools to still reload these files)
- there will be warnings for files which are locked by other processes
(at least on Windows). I'm usually seeing this for JAR files which are
not affected by eol-attribute changes at all.
One solution I could think of which might be helpful in other situations
as well would be to have an "--unobtrusive" option for reset which would
only replace a file if the content has actually been changed.
Marc.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Michael J Gruber <hidden> Date: 2016-06-15 22:50:22
Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
I'm looking for an unobtrusive way to apply (committed) changes for
text/eol attributes to the working tree. For instance, after having
changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
converted from CRLF to LF endings. The only advice I found so far is to
remove .git/index and do a reset --hard. The disadvantage of this
approach is that every file will be touched:
- although the content does not change, timestamps will be changed. This
The bytewise content does change.
makes tools like IDEs assume that the file content has been changed.
It may be that the content is semantically equivalent.
(Even if the timestamps would be properly reset, the replacement of the
files would have triggered system file change notifications and I'd
expect various tools to still reload these files)
- there will be warnings for files which are locked by other processes
(at least on Windows). I'm usually seeing this for JAR files which are
not affected by eol-attribute changes at all.
One solution I could think of which might be helpful in other situations
as well would be to have an "--unobtrusive" option for reset which would
only replace a file if the content has actually been changed.
How about
git ls-files \*.txt | xargs touch -a
git ls-files \*.txt | git checkout
?
From: Marc Strapetz <hidden> Date: 2016-06-15 22:50:22
On 11.01.2011 13:11, Michael J Gruber wrote:
Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
quoted
I'm looking for an unobtrusive way to apply (committed) changes for
text/eol attributes to the working tree. For instance, after having
changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
converted from CRLF to LF endings. The only advice I found so far is to
remove .git/index and do a reset --hard. The disadvantage of this
approach is that every file will be touched:
- although the content does not change, timestamps will be changed. This
The bytewise content does change.
The content has only changed for *.txt files, but the timestamps of
*all* files are updated. I guess (but didn't verify from code), that in
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
quoted
One solution I could think of which might be helpful in other situations
as well would be to have an "--unobtrusive" option for reset which would
only replace a file if the content has actually been changed.
How about
git ls-files \*.txt | xargs touch -a
git ls-files \*.txt | git checkout
From: Michael J Gruber <hidden> Date: 2016-06-15 22:50:25
Marc Strapetz venit, vidit, dixit 11.01.2011 15:02:
On 11.01.2011 13:11, Michael J Gruber wrote:
quoted
Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
quoted
I'm looking for an unobtrusive way to apply (committed) changes for
text/eol attributes to the working tree. For instance, after having
changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
converted from CRLF to LF endings. The only advice I found so far is to
remove .git/index and do a reset --hard. The disadvantage of this
approach is that every file will be touched:
- although the content does not change, timestamps will be changed. This
The bytewise content does change.
The content has only changed for *.txt files, but the timestamps of
*all* files are updated. I guess (but didn't verify from code), that in
Well, sure...
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
...but changing gitattributes is something you don't do routinely in
your workflow; so, at worst there would be an occasional unnecessary run
of your build process.
quoted
quoted
One solution I could think of which might be helpful in other situations
as well would be to have an "--unobtrusive" option for reset which would
only replace a file if the content has actually been changed.
How about
git ls-files \*.txt | xargs touch -a
git ls-files \*.txt | git checkout
That won't be helpful as it requires me to know what has changed.
But you do know that only (at most) *.txt have changed!
Michael
From: Marc Strapetz <hidden> Date: 2016-06-15 22:50:25
quoted
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
...but changing gitattributes is something you don't do routinely in
your workflow; so, at worst there would be an occasional unnecessary run
of your build process.
Our Git-SVN bridge does it, potentially on every pull. This is why we
currently need to run "rm .git/index && git reset --hard" after every
pull, resp. every checkout (switching to another commit may result in
changed .gitattributes as well).
If a "git checkout" would (optionally) make sure that all EOLs are
properly set according to .gitattributes, the problem would be resolved.
As this might be not so easy to implement, my suggestion was to make
"git reset --hard" work more unobtrusive. I think we can provide a
corresponding patch, if it has chances to get accepted.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.comhttp://blog.syntevo.com
On 13.01.2011 14:23, Michael J Gruber wrote:
Marc Strapetz venit, vidit, dixit 11.01.2011 15:02:
quoted
On 11.01.2011 13:11, Michael J Gruber wrote:
quoted
Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
quoted
I'm looking for an unobtrusive way to apply (committed) changes for
text/eol attributes to the working tree. For instance, after having
changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
converted from CRLF to LF endings. The only advice I found so far is to
remove .git/index and do a reset --hard. The disadvantage of this
approach is that every file will be touched:
- although the content does not change, timestamps will be changed. This
The bytewise content does change.
The content has only changed for *.txt files, but the timestamps of
*all* files are updated. I guess (but didn't verify from code), that in
Well, sure...
quoted
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
...but changing gitattributes is something you don't do routinely in
your workflow; so, at worst there would be an occasional unnecessary run
of your build process.
quoted
quoted
quoted
One solution I could think of which might be helpful in other situations
as well would be to have an "--unobtrusive" option for reset which would
only replace a file if the content has actually been changed.
How about
git ls-files \*.txt | xargs touch -a
git ls-files \*.txt | git checkout
That won't be helpful as it requires me to know what has changed.
But you do know that only (at most) *.txt have changed!
Michael
From: Michael J Gruber <hidden> Date: 2016-06-15 22:50:25
Marc Strapetz venit, vidit, dixit 13.01.2011 15:28:
quoted
quoted
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
...but changing gitattributes is something you don't do routinely in
your workflow; so, at worst there would be an occasional unnecessary run
of your build process.
Our Git-SVN bridge does it, potentially on every pull. This is why we
currently need to run "rm .git/index && git reset --hard" after every
pull, resp. every checkout (switching to another commit may result in
changed .gitattributes as well).
OK, now you're telling us what this is about ;)
If a "git checkout" would (optionally) make sure that all EOLs are
properly set according to .gitattributes, the problem would be resolved.
As this might be not so easy to implement, my suggestion was to make
"git reset --hard" work more unobtrusive. I think we can provide a
corresponding patch, if it has chances to get accepted.
There have been other cases where git update-index --really-refresh
wasn't enough. You might want to check whether that is a suitable "patch
attack vector". This might be useful not only for you but also for others.
Michael
From: Marc Strapetz <hidden> Date: 2016-06-15 22:50:25
quoted
If a "git checkout" would (optionally) make sure that all EOLs are
properly set according to .gitattributes, the problem would be resolved.
As this might be not so easy to implement, my suggestion was to make
"git reset --hard" work more unobtrusive. I think we can provide a
corresponding patch, if it has chances to get accepted.
There have been other cases where git update-index --really-refresh
wasn't enough. You might want to check whether that is a suitable "patch
attack vector". This might be useful not only for you but also for others.
So your suggestion is to fix "git update-index --really-refresh", so
it's a replacement for "rm .git/index"? This sounds reasonable,
especially as "rm .git/index" is something one feels not comfortable
about when performing the first time ;-)
Anyway, I'm still wondering if it will resolve the "git reset --hard"
problem of re-checking out every file, even if content is already
identical in the working tree. I think that part has to be fixed, too.
What do you think about "git checkout --fix-eols" option as an
alternative? Its uses cases are more limited, though.
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.comhttp://blog.syntevo.com
On 13.01.2011 15:37, Michael J Gruber wrote:
Marc Strapetz venit, vidit, dixit 13.01.2011 15:28:
quoted
quoted
quoted
case of missing .git/index, Git freshly writes all working tree files,
ignoring already existing files which already have the correct content.
Maybe this behavior is by intention and makes sense in some cases. In my
case it has adverse effects on IDEs and probably other tools which are
monitoring the file system.
...but changing gitattributes is something you don't do routinely in
your workflow; so, at worst there would be an occasional unnecessary run
of your build process.
Our Git-SVN bridge does it, potentially on every pull. This is why we
currently need to run "rm .git/index && git reset --hard" after every
pull, resp. every checkout (switching to another commit may result in
changed .gitattributes as well).
OK, now you're telling us what this is about ;)
quoted
If a "git checkout" would (optionally) make sure that all EOLs are
properly set according to .gitattributes, the problem would be resolved.
As this might be not so easy to implement, my suggestion was to make
"git reset --hard" work more unobtrusive. I think we can provide a
corresponding patch, if it has chances to get accepted.
There have been other cases where git update-index --really-refresh
wasn't enough. You might want to check whether that is a suitable "patch
attack vector". This might be useful not only for you but also for others.
Michael