Re: What's cooking in git.git (Nov 2012, #09; Wed, 28)

[Jeff King <peff@peff.net>]

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.

> * 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. Whereas if
something in $GIT_DIR is inaccessible, it's probably a serious problem.
So I think we have to manually use access_or_{warn,die} from each
callsite.

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[1]. 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.

-Peff

[1] We might want to eventually allow "config directories" where we
    would read all files in lexical order or something. So it is
    tempting to think of ignoring such entries as a
    forward-compatibility thing. But ignoring is the wrong thing; you
    probably would not want an old version of git to _ignore_ your
    config; it is better if it says "I am too old to understand your
    config format".