Jeff King <p...@peff.net> writes:
> On Wed, Nov 28, 2012 at 11:54:27AM -0800, Junio C Hamano wrote:
>> * jk/fsck-dot-in-trees (2012-11-28) 1 commit
>> - fsck: warn about '.' and '..' in trees
>> Will merge to 'next'.
> Do you have an opinion on warning about '.git', as well? It probably
> would make more sense as a patch on top, but I thought I'd ask before
> this got merged to next.
Yeah, it would make sense to reject what we would not record
ourselves when the tools are used in a sane manner.
>> * pf/editor-ignore-sigint (2012-11-11) 5 commits
>> - launch_editor: propagate SIGINT from editor to git
>> - run-command: do not warn about child death by SIGINT
>> - run-command: drop silent_exec_failure arg from wait_or_whine
>> - launch_editor: ignore SIGINT while the editor has control
>> - launch_editor: refactor to use start/finish_command
>> Avoid confusing cases where the user hits Ctrl-C while in the editor
>> session, not realizing git will receive the signal. Since most editors
>> will take over the terminal and will block SIGINT, this is not likely
>> to confuse anyone.
>> Some people raised issues with emacsclient, which are addressed by this
>> re-roll. It should probably also handle SIGQUIT, and there were a
>> handful of other review comments.
>> Expecting a re-roll.
> I'm slowly going through my post-travel/vacation/illness backlog. I hope
> to re-roll this one today or tomorrow.
>> * jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
>> - config: exit on error accessing any config file
>> - doc: advertise GIT_CONFIG_NOSYSTEM
>> - config: treat user and xdg config permission problems as errors
>> - config, gitignore: failure to access with ENOTDIR is ok
>> An RFC to deal with a situation where .config/git is a file and we
>> notice .config/git/config is not readable due to ENOTDIR, not
>> ENOENT; I think a bit more refactored approach to consistently
>> address permission errors across config, exclude and attrs is
>> desirable. Don't we also need a check for an opposite situation
>> where we open .config/git/config or .gitattributes for reading but
>> they turn out to be directories?
> I am not sure about the refactored approach you mention. We
> fundamentally need to treat in-tree attributes and exclude files more
> leniently, because we may find arbitrary paths in the tree.
> As far as the opposite situation, I do not know if it is worth worrying
> about. If $GIT_DIR/config or $HOME/.config/git/config is a directory,
> that is an error and we should flag it. In-tree is more hazy, but I
> think complaining is still the right thing. You cannot expect to store
> arbitrary crap at .gitattributes inside your tree. If you have crap in a
> file at such a path, we would read it and complain when its syntax is
> not that of a .gitattributes file. We should similarly complain when it
> is a directory.
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