Re: git status always modifies index?
I just got an answer to my stackoverflow question on this, apparently it's already implemented: https://stackoverflow.com/questions/47436939/how-to-run-git-status-without-modifying-git-index-such-as-in-a-prompt-command There is a "--no-optional-locks" command in 2.15 that looks like it does exactly what I need. -- Nathan On 11/22/17 10:10 AM, Santiago Torres wrote: On Wed, Nov 22, 2017 at 09:37:09AM -0600, Nathan Neulinger wrote: What I'm meaning is - why does it need to write the index back out to disk? From looking at the code in builtin/commit.c it looks like it takes a lock on the index, collects the status, and then unconditionally rewrites the index file. Hmm, I just took a look at those lines and I see what you mean. From what I understand, this is to cache the result of the index computation for ensuing git calls. I'm proposing that the update_index_if_able call not actually be issued if it would result in a ownership change on the underlying file - such as a simple case of root user or other privileged account issuing 'git status' in a directory. I don't think this would be a desire-able default behavior. I'd wager that running git status using different accounts is not a great idea --- specially interacting with a user repository as root. I understand completely that it would be expected to be altered if the privileged user did a commit/add or any other operation that was inherently a 'write' operation, but doesn't seem like status should be one of those cases. I think it's because of the reasons above. That being said, I don't know what the rest of the community would think of something akin to a --no-update-index type flag. Cheers! -Santiago. -- -------- Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412
Re: git status always modifies index?
What I'm meaning is - why does it need to write the index back out to disk? From looking at the code in builtin/commit.c it looks like it takes a lock on the index, collects the status, and then unconditionally rewrites the index file. I'm proposing that the update_index_if_able call not actually be issued if it would result in a ownership change on the underlying file - such as a simple case of root user or other privileged account issuing 'git status' in a directory. I understand completely that it would be expected to be altered if the privileged user did a commit/add or any other operation that was inherently a 'write' operation, but doesn't seem like status should be one of those cases. -- Nathan On 11/22/17 9:30 AM, Santiago Torres wrote: Hi Nathan. Do you mean git-status writing an index file? What would you suggest for git-status to compute which files have changed without modifying an index-file? Or are you suggesting git-status to fail if the index file doesn't belong to the user-id who invoked the command... Thanks, -Santiago -- Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412
git status always modifies index?
Current code appears to always attempt an index refresh, which results in file permission changes if you run a 'git status' as a privileged account. Would be nice if there were an option available to ask git status to NOT update the index. Even better would be if it was smart about the situation and would not refresh the index if it can see that file ownership would change as a result of updating the index. To me this is following principle of least surprise. Running a "query" operation would not normally be expected to result in write/modify activity. -- Nathan -------- Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412
Feature request - allow requesting a lock timeout
It appears that almost all of the locking calls in the current code use hold_lock_file_for_update() which translates into a request with zero timeout. This effectively means that for certain classes of usage, you can't use git concurrently without either external locking or retry logic. It would be nice to see a global option "--lock-timeout" that would request a specific non-zero default timeout for many of those operations. Even having the option to have a couple-second timeout would eliminate most typical concurrency issues, simplifying some automated use cases. Horrible/contrived example, but demonstrates the issue: for f in `seq 1 150`; do touch $f; (git add $f &); done You'll get a whole bunch of: fatal: Unable to create '/tmp/dummy/.git/index.lock': File exists. -- Nathan -------- Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
feature request - implement a GIT_AUTHOR_EMAIL equivalent, but processed BEFORE .gitconfig
Four related feature requests/ideas: 1. equivalent to GIT_*_EMAIL/NAME vars, but processed only if git config doesn't set values Right now, there isn't any way to have a systemwide profile script that tries to determine a better default for the user name/email values, such as in the case of shared logins. The best I've been able to do for now is use the 'EMAIL' var. Use case in my environment - most shared-login accounts are accessed via krb5 login, so it provides a nice way to set a better default for who is doing this commit than just the userid. 2. Setting option to user.name (or other setting) that would BLOCK the commit from occurring at all if it would otherwise fall back to defaults. I thought this previously worked by setting an empty value, but apparently doesn't work that way in current versions. 3. Setting option to user.name/user.email to prompt, SVN-style, for the name/email. Yes, this would be annoying/obnoxious to use normally, but intent is to avoid un-named root@host commits that would otherwise occur from user being lazy. 4. (This would accomplish all of the above) - enhance the include.path option to support the ! syntax similar to what aliases can do. i.e. [include] path = !/usr/local/bin/gen-git-env or [include] cmd = /usr/local/bin/gen-git-env -- Nathan Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature request - implement a GIT_AUTHOR_EMAIL equivalent, but processed BEFORE .gitconfig
I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean, but can you say more about the use case? What's wrong with the usual EMAIL environment variable? EMAIL actually worked for this case for me, but there wasn't any equivalent for author name, so the commits all look like sharedaccount myuser@mydomain. [...] [include] path = !/usr/local/bin/gen-git-env This is scary in terms of privilege escalation attacks. (Admin, could you please take a look at this repo? When I run 'git status', ) Wouldn't that be pulling from ~sharedaccount/.gitconfig anyway though? (Agreed that it could be an issue if you have shared ssh agent, krb5 tgts, etc. - but that would exist any time you connected into a shared account.) I would probably take the approach of not supporting that syntax in anything other than the per-user gitconfig file though as a safety measure - per-repo config could indeed be a problem. -- Nathan Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature request - implement a GIT_AUTHOR_EMAIL equivalent, but processed BEFORE .gitconfig
On 05/30/2014 02:48 PM, Junio C Hamano wrote: Nathan Neulinger nn...@neulinger.org writes: I wouldn't mind having a GIT_EMAIL envvar with the semantics you mean, but can you say more about the use case? What's wrong with the usual EMAIL environment variable? EMAIL actually worked for this case for me, but there wasn't any equivalent for author name, so the commits all look like sharedaccount myuser@mydomain. I do not want to go into the discussion on the sanity/insanity of using such a shared account, but I am guessing that you already have a concrete and workable mechanism in mind to allow you to set these environment variables such as GIT_WEAKER_AUTHOR_NAME to individual real users who share that account, and I further guess that that is what you use to set EMAIL. Am I guessing right? Yes, the behavior currently is: If I can figure out who, I'll set the EMAIL/attributes based on that. If not, it'll default to the don't know behavior that throws up the list Ideally, I'd prefer the second option be: Force user to specify --author if a good default can't be determined But there doesn't appear to be a way to do that. If so, wouldn't it be a better option to use that mechanism to set separate $HOME (or XDG_CONFIG_HOME if you prefer) to these real users who share the account, so that separate $HOME/.gitconfig files can be used by them? Not really, since there are lots of servers, and lots of application/service accounts. Where filesystem acl'ing can be used reasonably, it is, making this moot, but it still boils down to example case of I have a team of X people maintaining Y different applications, each on their own dedicated account. I'd just like a good mechanism to set defaults based on information other than what is in the home dir on the occasions that users log in directly to the app account, as opposed to doing updates offline on their own systems/to central repo/etc. -- Nathan Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
