Re: [git-users] Why git doesn't track file's read/write permission?
Yes, they are called deployment tools, which Git is not. One of the is git-deploy[1], but there are more out there. Also, I sense a design problem in your application if this is the case, although it's hard to tell from this much information. Best, Gergely [1] https://github.com/mislav/git-deploy On 28 Aug 2015 03:20, Enzo Chi enzo.chi...@gmail.com wrote: People make mistakes and if author change the permission and forget to change it back, that can't be corrected by software (GIT). Git never knows which file SHOULD be executable unless the author said so. The same as read only. My argument is: (keep read-only) 1. No harm 2. Do benefit some people 3. There's no technique issue to implement it. Off the topic, I use Emacs and there's extra key strokes to force write a read-only file without change file permission. So 99.9% I will not make that mistake. Now come back to my case: I need a global configuration file for a software. If it is modified by written some project specific information, when I run it in another project, simulation may fail and it may cost me a lot time to realize some crazy guy change it in another project. So, If git can't track it, is there any solution (Linux platform) to make sure selected files in repo are read-only after GIT operations (pull, merge, clone .etc) automatically? Thanks. On Thursday, August 27, 2015 at 11:53:55 AM UTC+10, charlesmanning wrote: On Thu, Aug 27, 2015 at 12:40 PM, Enzo Chi enzo@gmail.com wrote: I think git track executable permission, right? If so, files in git is read only and not deployment too, why it track x permission? x permissions alter the functionality of the file. For example, if you have a build system that needs scripts to build and those scripts need to be x, then the x better be stored or the scripts are useless. Keep read only permission is useful in some scenario. And most important thing is there's on harm to keep it (I am not a software developer, correct me if I am wrong)? That does not achieve anything from a safety perspective. If you lose/alter a file then you just checkout the version in HEAD again. Getting r/w permissions right would be hell anyway. Consider this: Start with a readonly file. Now I need to change it, so I make is locally writable and change it. Then I do a commit and push it again. Oops! I forgot to make it read only again before I pushed it, so now it is writable in the repo too. Better to just dodge this hangover by not having r/w. On Thursday, August 27, 2015 at 6:55:55 AM UTC+10, Philip Oakley wrote: I have post an question at http://superuser.com/questions/962861/how-to-use-git-to-commit-read-only-file I just want to know why GIT doesn't track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control) It's sort of a philosophical issue. If you are placing a file into a repository, it is by definition read only. You can never 'write' the same revision, but with a different content - it would be a contradiction. Hence the r/w flags are ignored. It's important to remember that as concieved, Git is not a deployment tool, so it didn't need r/w permissions, and as open source DVCS, everything checked out would be local so the user would have full control, so read-only couldn't be relied on anyway, and we hope the user will contribute a change/improvement so 'write' it is! Likewise it doesn't store timestamps (of the files) either.. There is a Linus 'rant' somewhere on the issue.. Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Why git doesn't track file's read/write permission?
People make mistakes and if author change the permission and forget to change it back, that can't be corrected by software (GIT). Git never knows which file SHOULD be executable unless the author said so. The same as read only. My argument is: (keep read-only) 1. No harm 2. Do benefit some people 3. There's no technique issue to implement it. Off the topic, I use Emacs and there's extra key strokes to force write a read-only file without change file permission. So 99.9% I will not make that mistake. Now come back to my case: I need a global configuration file for a software. If it is modified by written some project specific information, when I run it in another project, simulation may fail and it may cost me a lot time to realize some crazy guy change it in another project. So, If git can't track it, is there any solution (Linux platform) to make sure selected files in repo are read-only after GIT operations (pull, merge, clone .etc) automatically? Thanks. On Thursday, August 27, 2015 at 11:53:55 AM UTC+10, charlesmanning wrote: On Thu, Aug 27, 2015 at 12:40 PM, Enzo Chi enzo@gmail.com javascript: wrote: I think git track executable permission, right? If so, files in git is read only and not deployment too, why it track x permission? x permissions alter the functionality of the file. For example, if you have a build system that needs scripts to build and those scripts need to be x, then the x better be stored or the scripts are useless. Keep read only permission is useful in some scenario. And most important thing is there's on harm to keep it (I am not a software developer, correct me if I am wrong)? That does not achieve anything from a safety perspective. If you lose/alter a file then you just checkout the version in HEAD again. Getting r/w permissions right would be hell anyway. Consider this: Start with a readonly file. Now I need to change it, so I make is locally writable and change it. Then I do a commit and push it again. Oops! I forgot to make it read only again before I pushed it, so now it is writable in the repo too. Better to just dodge this hangover by not having r/w. On Thursday, August 27, 2015 at 6:55:55 AM UTC+10, Philip Oakley wrote: I have post an question at http://superuser.com/questions/962861/how-to-use-git-to-commit-read-only-file I just want to know why GIT doesn't track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control) It's sort of a philosophical issue. If you are placing a file into a repository, it is by definition read only. You can never 'write' the same revision, but with a different content - it would be a contradiction. Hence the r/w flags are ignored. It's important to remember that as concieved, Git is not a deployment tool, so it didn't need r/w permissions, and as open source DVCS, everything checked out would be local so the user would have full control, so read-only couldn't be relied on anyway, and we hope the user will contribute a change/improvement so 'write' it is! Likewise it doesn't store timestamps (of the files) either.. There is a Linus 'rant' somewhere on the issue.. Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Why git doesn't track file's read/write permission?
I have post an question at http://superuser.com/questions/962861/how-to-use-git-to-commit-read-only-file I just want to know why GIT doesn't track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control) It's sort of a philosophical issue. If you are placing a file into a repository, it is by definition read only. You can never 'write' the same revision, but with a different content - it would be a contradiction. Hence the r/w flags are ignored. It's important to remember that as concieved, Git is not a deployment tool, so it didn't need r/w permissions, and as open source DVCS, everything checked out would be local so the user would have full control, so read-only couldn't be relied on anyway, and we hope the user will contribute a change/improvement so 'write' it is! Likewise it doesn't store timestamps (of the files) either.. There is a Linus 'rant' somewhere on the issue.. Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Why git doesn't track file's read/write permission?
I have post an question at http://superuser.com/questions/962861/how-to-use-git-to-commit-read-only-file I just want to know why GIT doesn't track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control) -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Why git doesn't track file's read/write permission?
I think git track executable permission, right? If so, files in git is read only and not deployment too, why it track x permission? Keep read only permission is useful in some scenario. And most important thing is there's on harm to keep it (I am not a software developer, correct me if I am wrong)? On Thursday, August 27, 2015 at 6:55:55 AM UTC+10, Philip Oakley wrote: I have post an question at http://superuser.com/questions/962861/how-to-use-git-to-commit-read-only-file I just want to know why GIT doesn't track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control) It's sort of a philosophical issue. If you are placing a file into a repository, it is by definition read only. You can never 'write' the same revision, but with a different content - it would be a contradiction. Hence the r/w flags are ignored. It's important to remember that as concieved, Git is not a deployment tool, so it didn't need r/w permissions, and as open source DVCS, everything checked out would be local so the user would have full control, so read-only couldn't be relied on anyway, and we hope the user will contribute a change/improvement so 'write' it is! Likewise it doesn't store timestamps (of the files) either.. There is a Linus 'rant' somewhere on the issue.. Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Why git doesn't track file's read/write permission?
On Thu, Aug 27, 2015 at 12:40 PM, Enzo Chi enzo.chi...@gmail.com wrote: I think git track executable permission, right? If so, files in git is read only and not deployment too, why it track x permission? x permissions alter the functionality of the file. For example, if you have a build system that needs scripts to build and those scripts need to be x, then the x better be stored or the scripts are useless. Keep read only permission is useful in some scenario. And most important thing is there's on harm to keep it (I am not a software developer, correct me if I am wrong)? That does not achieve anything from a safety perspective. If you lose/alter a file then you just checkout the version in HEAD again. Getting r/w permissions right would be hell anyway. Consider this: Start with a readonly file. Now I need to change it, so I make is locally writable and change it. Then I do a commit and push it again. Oops! I forgot to make it read only again before I pushed it, so now it is writable in the repo too. Better to just dodge this hangover by not having r/w. On Thursday, August 27, 2015 at 6:55:55 AM UTC+10, Philip Oakley wrote: I have post an question at http://superuser.com/questions/962861/how-to-use-git-to-commit-read-only-file I just want to know why GIT doesn't track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control) It's sort of a philosophical issue. If you are placing a file into a repository, it is by definition read only. You can never 'write' the same revision, but with a different content - it would be a contradiction. Hence the r/w flags are ignored. It's important to remember that as concieved, Git is not a deployment tool, so it didn't need r/w permissions, and as open source DVCS, everything checked out would be local so the user would have full control, so read-only couldn't be relied on anyway, and we hope the user will contribute a change/improvement so 'write' it is! Likewise it doesn't store timestamps (of the files) either.. There is a Linus 'rant' somewhere on the issue.. Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
