[PATCH] core.hidedotfiles: only hide '.git' dir by default

[Erik Faye-Lund]

Currently we hide everything starting with a dot by
default.

This patch adds a new config option for core.hidedotfiles
called "dotgitonly", that only hides the '.git'-file. This
is the new default setting.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---
builtin-init-db.c | 9 +++++++++
cache.h | 8 +++++++-
compat/mingw.c | 12 +++++++-----
compat/mingw.h | 1 +
config.c | 4 ++++
environment.c | 2 +-
6 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index dd84cae..1c68e4c 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -280,6 +280,14 @@ static int create_default_files(const char *template_path)
return reinit;
}

+static void mark_as_git_dir(const char *dir)
+{
+#ifdef WIN32
+ if (hide_dotfiles != HIDE_DOTFILES_FALSE && make_hidden(dir))
+ warning("Failed to make '%s' hidden", dir);
+#endif
+}
+
int init_db(const char *template_dir, unsigned int flags)
{
const char *sha1_dir;
@@ -287,6 +295,7 @@ int init_db(const char *template_dir, unsigned int flags)
int len, reinit;

safe_create_dir(get_git_dir(), 0);
+ mark_as_git_dir(get_git_dir());

init_is_bare_repository = is_bare_repository();

diff --git a/cache.h b/cache.h
index 767a50e..d3bfe0d 100644
--- a/cache.h
+++ b/cache.h
@@ -525,7 +525,13 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
-extern int hide_dotfiles;
+
+enum hide_dotfiles_type {
+ HIDE_DOTFILES_FALSE = 0,
+ HIDE_DOTFILES_TRUE,
+ HIDE_DOTFILES_DOTGITONLY,
+};
+extern enum hide_dotfiles_type hide_dotfiles;

enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/compat/mingw.c b/compat/mingw.c
index 2424380..c10acc9 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -4,8 +4,8 @@
#include <winioctl.h>
#include <shellapi.h>
#include "../strbuf.h"
+#include "../cache.h"

-extern int hide_dotfiles;
unsigned int _CRT_fmode = _O_BINARY;

static int err_win_to_posix(DWORD winerr)
@@ -121,7 +121,7 @@ static int err_win_to_posix(DWORD winerr)
return error;
}

-static int make_hidden(const char *path)
+int make_hidden(const char *path)
{
DWORD attribs = GetFileAttributes(path);
if (SetFileAttributes(path, FILE_ATTRIBUTE_HIDDEN | attribs))
@@ -134,7 +134,7 @@ static int make_hidden(const char *path)
int mingw_mkdir(const char *path, int mode)
{
int ret = mkdir(path);
- if (!ret && hide_dotfiles) {
+ if (!ret && hide_dotfiles != HIDE_DOTFILES_TRUE) {
/*
* In Windows a file or dir starting with a dot is not
* automatically hidden. So lets mark it as hidden when
@@ -168,7 +168,8 @@ int mingw_open (const char *filename, int oflags, ...)
if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
errno = EISDIR;
}
- if ((oflags & O_CREAT) && fd >= 0 && hide_dotfiles) {
+ if ((oflags & O_CREAT) && fd >= 0 &&
+ hide_dotfiles == HIDE_DOTFILES_TRUE) {
/*
* In Windows a file or dir starting with a dot is not
* automatically hidden. So lets mark it as hidden when
@@ -186,7 +187,8 @@ FILE *mingw_fopen (const char *filename, const char *mode)
{
int hide = 0;
FILE *file;
- if (hide_dotfiles && basename((char*)filename)[0] == '.')
+ if (hide_dotfiles == HIDE_DOTFILES_TRUE &&
+ basename((char*)filename)[0] == '.')
hide = access(filename, F_OK);

file = fopen(filename, mode);
diff --git a/compat/mingw.h b/compat/mingw.h
index 1b528da..4a4c69f 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -224,6 +224,7 @@ void mingw_open_html(const char *path);

char **make_augmented_environ(const char *const *vars);
void free_environ(char **env);
+int make_hidden(const char *path);

/*
* A replacement of main() that ensures that argv[0] has a path
diff --git a/config.c b/config.c
index 49010e4..c8cdb81 100644
--- a/config.c
+++ b/config.c
@@ -504,6 +504,10 @@ static int git_default_core_config(const char *var, const char *value)
}

if (!strcmp(var, "core.hidedotfiles")) {
+ if (value && !strcasecmp(value, "dotgitonly")) {
+ hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;
+ return 0;
+ }
hide_dotfiles = git_config_bool(var, value);
return 0;
}
diff --git a/environment.c b/environment.c
index ea1abbf..ccbae17 100644
--- a/environment.c
+++ b/environment.c
@@ -50,7 +50,7 @@ enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
#endif
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
int grafts_replace_parents = 1;
-int hide_dotfiles = 1;
+enum hide_dotfiles_type hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;

/* Parallel index stat data preload? */
int core_preload_index = 0;
--
1.6.5.1.1372.g44a79

[Junio C Hamano]

Erik Faye-Lund <kusm...@googlemail.com> writes:

> diff --git a/builtin-init-db.c b/builtin-init-db.c
> index dd84cae..1c68e4c 100644
> --- a/builtin-init-db.c
> +++ b/builtin-init-db.c
> @@ -280,6 +280,14 @@ static int create_default_files(const char *template_path)
> return reinit;
> }
>
> +static void mark_as_git_dir(const char *dir)
> +{
> +#ifdef WIN32
> + if (hide_dotfiles != HIDE_DOTFILES_FALSE && make_hidden(dir))
> + warning("Failed to make '%s' hidden", dir);
> +#endif
> +}
> +

Ouch. I was thinking more along the lines of...

* in git-compat-util.h

#ifndef mark_as_git_dir
#define mark_as_git_dir(x) /* noop */
#endif

* in compat/mingw/somewhere.h

#define mark_as_git_dir(x) mingw_mark_as_git_dir(x)

* in compat/mingw/somewhere.c

void mingw_mark_as_git_dir(const char *dir)
{
...
}

without exposing an extra #ifdef WIN32 to generic part of the codebase.

Also given that the topic of #288 was about ".git", don't you want to rip
out the code to hide ".anything" that is in compat/mingw.c? Otherwise the
introduction of mark_as_git_dir() interface to treat ".git" as something
special doesn't make much sense to me.

[Erik Faye-Lund]

Ah, Yeah. I did consider that, but I thought it would make it tricky
for multiple platforms to share code or whatnot, but I guess that's
unlikely to happen in the first place. I'll post an updated patch
tomorrow if I find the time.

> Also given that the topic of #288 was about ".git", don't you want to rip
> out the code to hide ".anything" that is in compat/mingw.c?  Otherwise the
> introduction of mark_as_git_dir() interface to treat ".git" as something
> special doesn't make much sense to me.
>

I'm not sure I get what you mean. You want to remove the "true"-value
from core.hidedotfiles? I'm basically doing what Dscho suggested
(unless I misunderstood him), adding "dotGitOnly" as a new value for
core.hidedotfiles.

But looking at the code, I think I see some typos. I'm too tired now ;)

--
Erik "kusma" Faye-Lund

[Erik Faye-Lund]

Currently we hide everything starting with a dot by
default.

This patch adds a new config option for core.hidedotfiles
called "dotgitonly", that only hides the '.git'-file. This
is the new default setting.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---

builtin-init-db.c | 1 +
cache.h | 8 +++++++-
compat/mingw.c | 16 ++++++++++++----
compat/mingw.h | 3 +++

config.c | 4 ++++
environment.c | 2 +-

git-compat-util.h | 4 ++++
7 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index dd84cae..42580f6 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -287,6 +287,7 @@ int init_db(const char *template_dir, unsigned int flags)

int len, reinit;

safe_create_dir(get_git_dir(), 0);
+ mark_as_git_dir(get_git_dir());

init_is_bare_repository = is_bare_repository();

diff --git a/cache.h b/cache.h
index 767a50e..d3bfe0d 100644
--- a/cache.h
+++ b/cache.h
@@ -525,7 +525,13 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
-extern int hide_dotfiles;
+
+enum hide_dotfiles_type {
+ HIDE_DOTFILES_FALSE = 0,
+ HIDE_DOTFILES_TRUE,
+ HIDE_DOTFILES_DOTGITONLY,
+};
+extern enum hide_dotfiles_type hide_dotfiles;

enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/compat/mingw.c b/compat/mingw.c

index 2424380..45c5a19 100644

--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -4,8 +4,8 @@
#include <winioctl.h>
#include <shellapi.h>
#include "../strbuf.h"
+#include "../cache.h"

-extern int hide_dotfiles;
unsigned int _CRT_fmode = _O_BINARY;

static int err_win_to_posix(DWORD winerr)

@@ -130,11 +130,17 @@ static int make_hidden(const char *path)
return -1;
}

+void mingw_mark_as_git_dir(const char *dir)
+{

+ if (hide_dotfiles != HIDE_DOTFILES_FALSE && make_hidden(dir))
+ warning("Failed to make '%s' hidden", dir);
+}

+
#undef mkdir

int mingw_mkdir(const char *path, int mode)
{
int ret = mkdir(path);
- if (!ret && hide_dotfiles) {

+ if (!ret && hide_dotfiles == HIDE_DOTFILES_TRUE) {

/*
* In Windows a file or dir starting with a dot is not
* automatically hidden. So lets mark it as hidden when

@@ -168,7 +174,8 @@ int mingw_open (const char *filename, int oflags, ...)

if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
errno = EISDIR;
}
- if ((oflags & O_CREAT) && fd >= 0 && hide_dotfiles) {
+ if ((oflags & O_CREAT) && fd >= 0 &&
+ hide_dotfiles == HIDE_DOTFILES_TRUE) {
/*
* In Windows a file or dir starting with a dot is not
* automatically hidden. So lets mark it as hidden when

@@ -186,7 +193,8 @@ FILE *mingw_fopen (const char *filename, const char *mode)

{
int hide = 0;
FILE *file;
- if (hide_dotfiles && basename((char*)filename)[0] == '.')
+ if (hide_dotfiles == HIDE_DOTFILES_TRUE &&
+ basename((char*)filename)[0] == '.')
hide = access(filename, F_OK);

file = fopen(filename, mode);
diff --git a/compat/mingw.h b/compat/mingw.h

index 1b528da..852db2e 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -218,6 +218,9 @@ int winansi_fprintf(FILE *stream, const char *format, ...) __attribute__((format
void mingw_open_html(const char *path);
#define open_html mingw_open_html

+void mingw_mark_as_git_dir(const char *dir);
+#define mark_as_git_dir mingw_mark_as_git_dir
+
/*
* helpers
*/

diff --git a/config.c b/config.c
index 49010e4..c8cdb81 100644
--- a/config.c
+++ b/config.c
@@ -504,6 +504,10 @@ static int git_default_core_config(const char *var, const char *value)
}

if (!strcmp(var, "core.hidedotfiles")) {
+ if (value && !strcasecmp(value, "dotgitonly")) {
+ hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;
+ return 0;
+ }
hide_dotfiles = git_config_bool(var, value);
return 0;
}
diff --git a/environment.c b/environment.c
index ea1abbf..ccbae17 100644
--- a/environment.c
+++ b/environment.c
@@ -50,7 +50,7 @@ enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
#endif
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
int grafts_replace_parents = 1;
-int hide_dotfiles = 1;
+enum hide_dotfiles_type hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;

/* Parallel index stat data preload? */
int core_preload_index = 0;

diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..db19559 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -464,4 +464,8 @@ void git_qsort(void *base, size_t nmemb, size_t size,
*/
int unlink_or_warn(const char *path);

+#ifndef mark_as_git_dir
+#define mark_as_git_dir(x) /* noop */
+#endif
+
#endif
--
1.6.5.1.1372.g025e4.dirty

[Erik Faye-Lund]

Ping, what's the status here? I'd expect to see this included in
Dscho's or Hannes' repo by now, but I cant find it...

--
Erik "kusma" Faye-Lund

[Junio C Hamano]

Erik Faye-Lund <kusm...@googlemail.com> writes:

> Ping, what's the status here? I'd expect to see this included in
> Dscho's or Hannes' repo by now, but I cant find it...

If core.hidedotfiles is not already in wide use, I'd be happier if there
isn't such a three-value configuration variable that can bite unsuspecting
users, if the end result will eventually be merged into my tree. I've
already explained why it is not git's job to mark dot-files as "hidden" on
Windows in the earlier discussion.

I'd suggest to either

(1) mark .git (and only .git) as "hidden" without adding the
configuration variable (i.e. do it unconditionally); or

(2) have the configuration but make it a boolean (defaults to true) that
tells us to mark .git (and only .git) as "hidden"..

[Erik Faye-Lund]

I only did what Dscho said[1] ('Maybe I haven't repeated myself often
enough? A patch adding support for "core.hideDotFiles =
dotGitOnly" would be welcome [...]'). Perhaps I interpreted him incorrectly.

Personally I'd prefer (1) due to the reduced amount of code, but I
have no objection to (2). Dscho, are you fine with going for (2)?

[1] http://groups.google.com/group/msysgit/browse_thread/thread/4d41c279ab0f2051/a5453063a084b9af#a5453063a084b9af

--
Erik "kusma" Faye-Lund

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Junio C Hamano wrote:

> Erik Faye-Lund <kusm...@googlemail.com> writes:
>
> > Ping, what's the status here? I'd expect to see this included in
> > Dscho's or Hannes' repo by now, but I cant find it...

I did not have any access to any Windows machine.

> If core.hidedotfiles is not already in wide use, I'd be happier if there
> isn't such a three-value configuration variable that can bite
> unsuspecting users, if the end result will eventually be merged into my
> tree. I've already explained why it is not git's job to mark dot-files
> as "hidden" on Windows in the earlier discussion.
>
> I'd suggest to either
>
> (1) mark .git (and only .git) as "hidden" without adding the
> configuration variable (i.e. do it unconditionally); or
>
> (2) have the configuration but make it a boolean (defaults to true) that
> tells us to mark .git (and only .git) as "hidden"..

If dot files should be hidden, then making all of them hidden by default
would be the right thing.

We have to work around certain buggy software, that is the only reason why
we cannot do it.

But I would rather keep the tristate, because it allows the user to say
what to do, defaulting to hideDotGit.

Will apply and test later (it is all so slow, especially in an emulator),
Dscho

[Erik Faye-Lund]

On Fri, Jan 8, 2010 at 2:47 PM, Johannes Schindelin
<Johannes....@gmx.de> wrote:
> If dot files should be hidden, then making all of them hidden by default
> would be the right thing.
>
> We have to work around certain buggy software, that is the only reason why
> we cannot do it.
>
> But I would rather keep the tristate, because it allows the user to say
> what to do, defaulting to hideDotGit.
>
> Will apply and test later (it is all so slow, especially in an emulator),
> Dscho
>

What I'm wondering a bit about is why we should even hide dot-files
(apart from the .git-folder, which is special in that it isn't a
tracked file at all) in the first place.

Git doesn't track attributes, and if a user needs to make sure all
dot-files are hidden on Windows, wouldn't this be more suitable to do
in a custom post-checkout hook?

--
Erik "kusma" Faye-Lund

[Junio C Hamano]

Johannes Schindelin <Johannes....@gmx.de> writes:

>> I'd suggest to either
>>
>> (1) mark .git (and only .git) as "hidden" without adding the
>> configuration variable (i.e. do it unconditionally); or
>>
>> (2) have the configuration but make it a boolean (defaults to true) that
>> tells us to mark .git (and only .git) as "hidden"..
>
> If dot files should be hidden, then making all of them hidden by default
> would be the right thing.

I wouldn't insist strongly (I lack incentive, as I don't use Windows), but
I think you are looking at this issue in a wrong way.

I see that the desired effect from higher level is "hide the $GIT_DIR (at
least by default), as end users don't have any business seeing it". Using
a name ".git" for $GIT_DIR is an implementation detail that happened to
work well for that purpose on Unices.

In other words, the final goal never is "We should hide all dotfiles".
"ls" without "-a" doesn't show ".foobar" just like it does not show
".git", but that is not what _we_ arrange to do ourselves. In fact we
don't _care_ how ".foobar" is shown even on Unices.

If you agree that the goal is "hide the $GIT_DIR (at least by default)",
then you would agree that"making all of them hidden by default" is not the
right thing at all.

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Erik Faye-Lund wrote:

> On Fri, Jan 8, 2010 at 2:47 PM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> > If dot files should be hidden, then making all of them hidden by default
> > would be the right thing.
> >
> > We have to work around certain buggy software, that is the only reason why
> > we cannot do it.
> >
> > But I would rather keep the tristate, because it allows the user to say
> > what to do, defaulting to hideDotGit.
> >
> > Will apply and test later (it is all so slow, especially in an emulator),
> > Dscho
> >
>
> What I'm wondering a bit about is why we should even hide dot-files
> (apart from the .git-folder, which is special in that it isn't a
> tracked file at all) in the first place.

First, it was an explicit user request.

And second, I really have to say strongly that .git is _not_ special when
it comes to it being hidden. Not at all. Either you see hidden files
("ls -a"), or you don't ("ls").

So I sincerely think that the user request was granted best the way we did
it. Now, Eclipse is a big piece of code (read: PoC), and we are way
faster working around their bug than they are fixing it.

So I agree the pragmatic thing is to hide .git/ only by default. But it
is wrong. It is just a work-around. And I strongly disagree with Junio
who seems to suggest that we should not even allow the correct thing to be
chosen by the user (who might not wish to use Eclipse, after all).

Ciao,
Dscho

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Junio C Hamano wrote:

> In other words, the final goal never is "We should hide all dotfiles".

The whole point of adding a file with a dot in the beginning is to hide it
by default.

> "ls" without "-a" doesn't show ".foobar" just like it does not show
> ".git", but that is not what _we_ arrange to do ourselves.

The equivalent on Windows to "-a" is to enable the "show hidden files"
option in Explorer.

BTW this issue makes all signs to get over-discussed, it should be
all-too-clear already,
Dscho

[Junio C Hamano]

Johannes Schindelin <Johannes....@gmx.de> writes:

>> What I'm wondering a bit about is why we should even hide dot-files
>> (apart from the .git-folder, which is special in that it isn't a
>> tracked file at all) in the first place.
>
> First, it was an explicit user request.

And as the project manager, you have both freedom and obligation to your
users to judge if the request makes sense in the context of the project
and target audience.

> And second, I really have to say strongly that .git is _not_ special when
> it comes to it being hidden. Not at all. Either you see hidden files
> ("ls -a"), or you don't ("ls").

Try opening Notepad, type some string, and save it as ".dotfile.txt". View
the containing folder in Explorer. Is it hidden?

If the end user wants to arrange ".dotfile.txt" not be shown, the right
way to do so would be to configure Explorer or whatever to not show the
dotfiles (I don't do nor know Windows, so I don't know if it is possible
or how it is done. Perhaps there is an Explorer extension to do this?),
whether the folder is managed by msysgit or just plain Windows thing.

If the platform default is not to treat ".dotfile.txt" any specially from
"nondotfile.txt" by hiding, why should msysgit managed folder behave any
differently? As Erik says, I think that should be left up to the end user
preference.

I wouldn't object if your argument were "if we were to hide .git because
it is $GIT_DIR that is special, we should have a way, to help people who
don't use broken IDE that cannot open .dotfiles, to tell git to hide other
files that are special to git, gitignore, .gitattributes and .gitmodules".
I would also agree if you added "... and the same option should hide any
dotfile that begins with ".git" as we might add friends to these three
existing exceptions in the future" to that.

But I don't think we have any business hiding ".foo" from the users.

[Erik Faye-Lund]

>> What I'm wondering a bit about is why we should even hide dot-files
>> (apart from the .git-folder, which is special in that it isn't a
>> tracked file at all) in the first place.
>
> First, it was an explicit user request.

Wasn't the user request only about hiding $GIT_DIR? Is there some
other request on this (apart from issue 288) that I missed?

> And second, I really have to say strongly that .git is _not_ special when
> it comes to it being hidden.  Not at all.  Either you see hidden files
> ("ls -a"), or you don't ("ls").

I think I disagree here. It is different because it "belongs" to git.
It's not the tracked content, it's something the user shouldn't mess
with.

As Junio said, ".git" was hidden because it is hidden on UNIX, so we
_know_ that this should be hidden.

> The whole point of adding a file with a dot in the beginning is to hide it
> by default.

I don't think we can assume that. It is probably true for
cross-platform projects, but for Windows-only projects I'd say that
hiding dot-files is insane.

While I agree that the Eclipse bug (where this becomes a real problem
for the user, not just an annoyance) is brain-dead, i think we're
taking on responsibility that isn't ours.

On Fri, Jan 8, 2010 at 3:30 PM, Junio C Hamano <git...@pobox.com> wrote:
> I wouldn't object if your argument were "if we were to hide .git because
> it is $GIT_DIR that is special, we should have a way, to help people who
> don't use broken IDE that cannot open .dotfiles, to tell git to hide other
> files that are special to git, gitignore, .gitattributes and .gitmodules".
> I would also agree if you added "... and the same option should hide any
> dotfile that begins with ".git" as we might add friends to these three
> existing exceptions in the future" to that.
>
> But I don't think we have any business hiding ".foo" from the users.
>

I'm a little skeptical to hiding .gitignore etc also. Imagine if I
have installed a shell extension that displays overlay-icons on files
and folders that indicate modifications. I'd be really confused if a
folder was marked as modified (because some of the files in it were
modified), but I couldn't see any modified files in side it (perhaps
because I had autocrlf turned on and there's a .gitignore with CRLFs
in the repo). Especially since git doesn't track folders at all.

I think the user should be free to hide the folders he wants to, but I
doubt that we're the ones who shouldn't do this for him.

--
Erik "kusma" Faye-Lund

[Junio C Hamano]

Erik Faye-Lund <kusm...@googlemail.com> writes:

> On Fri, Jan 8, 2010 at 3:30 PM, Junio C Hamano <git...@pobox.com> wrote:
>> I wouldn't object if your argument were "if we were to hide .git because
>> it is $GIT_DIR that is special, we should have a way, to help people who
>> don't use broken IDE that cannot open .dotfiles, to tell git to hide other
>> files that are special to git, gitignore, .gitattributes and .gitmodules".
>> I would also agree if you added "... and the same option should hide any
>> dotfile that begins with ".git" as we might add friends to these three
>> existing exceptions in the future" to that.
>>
>> But I don't think we have any business hiding ".foo" from the users.
>
> I'm a little skeptical to hiding .gitignore etc also. Imagine if I
> have installed a shell extension that displays overlay-icons on files
> and folders that indicate modifications. I'd be really confused if a
> folder was marked as modified (because some of the files in it were
> modified), but I couldn't see any modified files in side it (perhaps
> because I had autocrlf turned on and there's a .gitignore with CRLFs
> in the repo). Especially since git doesn't track folders at all.
>
> I think the user should be free to hide the folders he wants to, but I
> doubt that we're the ones who shouldn't do this for him.

I actually don't care too strongly about ".git[a-z]*" files either way,
even though I do care about not hiding ".frotz" _if_ it is the default
behaviour in Windows not to hide dotfiles.

This is about consistency. Dscho wants consistency across experiences
with git implementations on different platforms. My rephrasing of his
argument goes like this:

By default on Unices any dotfiles in git managed directories are not
seen, so on Windows any dotfiles in msysgit managed folders should be
hidden, and the user experience is consistent between the platforms.

My point, phrased in terms of consistency is:

By default on Windows any dotfiles anywhere are not hidden. Even if a
folder is managed by msysgit, we shouldn't hide random dotfiles, in
order to give consistent user experience with other Windows programs.

$GIT_DIR is special in that the end users aren't supposed to directly
muck with it, and it also is consistent with the platform convention
that it is customary for programs to make folders they use to store
their own control information hidden [*1*]. So hiding it is more
consistent with platform convention.

If this were about Cygwin port of git, I wouldn't have sent any message to
this thread---the whole point of Cygwin is to bring POSIX user experience
to Windows users. But I've always thought that the point of msysgit was
to be a more consistent Windows citizen than Cygwin is, because Cygwin
experience felt too "oddball" to Windows users, and people wanted a port
that is closer to "native".

[Footnote]

*1* I don't know if this last part is true, but I am guessing the reason
why the initial complaint came was because msysgit doesn't hide $GIT_DIR
when other SCM hides theirs. If that is not the case, perhaps we
shouldn't even be hiding $GIT_DIR.

[Erik Faye-Lund]

On Fri, Jan 8, 2010 at 4:08 PM, Junio C Hamano <git...@pobox.com> wrote:
> Erik Faye-Lund <kusm...@googlemail.com> writes:
>
>> On Fri, Jan 8, 2010 at 3:30 PM, Junio C Hamano <git...@pobox.com> wrote:
>>> I wouldn't object if your argument were "if we were to hide .git because
>>> it is $GIT_DIR that is special, we should have a way, to help people who
>>> don't use broken IDE that cannot open .dotfiles, to tell git to hide other
>>> files that are special to git, gitignore, .gitattributes and .gitmodules".
>>> I would also agree if you added "... and the same option should hide any
>>> dotfile that begins with ".git" as we might add friends to these three
>>> existing exceptions in the future" to that.
>>>
>>> But I don't think we have any business hiding ".foo" from the users.
>>
>> I'm a little skeptical to hiding .gitignore etc also. Imagine if I
>> have installed a shell extension that displays overlay-icons on files
>> and folders that indicate modifications. I'd be really confused if a
>> folder was marked as modified (because some of the files in it were
>> modified), but I couldn't see any modified files in side it (perhaps
>> because I had autocrlf turned on and there's a .gitignore with CRLFs
>> in the repo). Especially since git doesn't track folders at all.
>>
>> I think the user should be free to hide the folders he wants to, but I
>> doubt that we're the ones who shouldn't do this for him.
>
> I actually don't care too strongly about ".git[a-z]*" files either way,
> even though I do care about not hiding ".frotz" _if_ it is the default
> behaviour in Windows not to hide dotfiles.
>

Just for the record (I'm assuming that everyone involved already know
this): It is default behavior of Windows not to hide dotfiles. If it
wasn't, we wouldn't have needed a patch in the first place.

--
Erik "kusma" Faye-Lund

[Johannes Sixt]

On Freitag, 8. Januar 2010, Johannes Schindelin wrote:
> On Fri, 8 Jan 2010, Junio C Hamano wrote:
> > In other words, the final goal never is "We should hide all dotfiles".
>
> The whole point of adding a file with a dot in the beginning is to hide it
> by default.

Not so on Windows. Just because git happened to choose the names .gitignore
and .gitattributes that happen to be "hidden" on Unix, does not mean that
this must also be the case on Windows.

> > "ls" without "-a" doesn't show ".foobar" just like it does not show
> > ".git", but that is not what _we_ arrange to do ourselves.
>
> The equivalent on Windows to "-a" is to enable the "show hidden files"
> option in Explorer.

You are only correct as far as the *tool* to show hidden files is concerned.

But this does not answer which files should be hidden in the first place.
Requiring dot-files to be hidden on Windows forces a Unix mindset onto a
user-base that has completely different expectations.

-- Hannes

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Erik Faye-Lund wrote:

> As Junio said, ".git" was hidden because it is hidden on UNIX, so we
> _know_ that this should be hidden.

There is a real strong tradition on Windows not to start a file with a dot
_at all_. So all of the concerns of both of you appear a little bit moot.

Just to summarize: if it would be wrong to mark dot files as hidden in
general, so would it be to mark .git/.

This is getting ridiculous,
Dscho

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Johannes Sixt wrote:

> On Freitag, 8. Januar 2010, Johannes Schindelin wrote:
> > On Fri, 8 Jan 2010, Junio C Hamano wrote:
> > > In other words, the final goal never is "We should hide all dotfiles".
> >
> > The whole point of adding a file with a dot in the beginning is to hide it
> > by default.
>
> Not so on Windows. Just because git happened to choose the names .gitignore
> and .gitattributes that happen to be "hidden" on Unix, does not mean that
> this must also be the case on Windows.

So, .gitignore and .gitattributes start with a dot for another reason than
to hide them by default? You must be kidding me.

> > > "ls" without "-a" doesn't show ".foobar" just like it does not show
> > > ".git", but that is not what _we_ arrange to do ourselves.
> >
> > The equivalent on Windows to "-a" is to enable the "show hidden files"
> > option in Explorer.
>
> You are only correct as far as the *tool* to show hidden files is
> concerned.

Right, because unsurprisingly, "ls" does not show dot files (including
.git/) while "ls -a" does (including .git/).

> But this does not answer which files should be hidden in the first
> place. Requiring dot-files to be hidden on Windows forces a Unix mindset
> onto a user-base that has completely different expectations.

And of course, Windows is such a different beast than Unix, and it is
obvious that developers segregate even more into non-platform-independent
projects?

As I said, this discussion is getting _really_ ridiculous,
Dscho

[Junio C Hamano]

Erik Faye-Lund <kusm...@googlemail.com> writes:

> As Junio said, ".git" was hidden because it is hidden on UNIX, so we
> _know_ that this should be hidden.

That is not quite what I said (it is exactly the other way around), and
can solicit deliberate and ridiculous misinterpretation.

We named ".git", ".gitignore", ".gitattributes" and ".gitmodules" starting
with dot because we wanted to hide them and starting the names with dot
was a convenient and established way to do so on Unices.

Among these, ".git" is undisputably *not* end-user contents. Others,
while they are tracked end-user contents, do mean special things to git.

So if msysgit folks want to replicate the "git experience" between Unices
and Windows, it is _perfectly fine_ to hide ".git", and it also is
acceptable to make these other ".git*" files hidden.

Notice that the above does not say _anything_ about other files that are
end-user contents and do not have any special meaning to git. We don't
care if they are hidden or not on Unices; how they are presented should
follow the platform convention and tweaking that is entirely up to the end
user preference (think "alias ls ls -A").

By "the end user preference", I don't mean core.hidedotfiles variable set
to "all". That will bring us back to the "why msysgit managed folders are
special? Is it really a native Windows port?" problem. The end user
preference would instead be expressed by setting any file or folder as
"hidden" with a native Windows method outside "git" proper.

It is a separate problem if it is cumbersome to run around to find files
whose names begin with a dot in your nested folders with Explorer, opening
Properties and setting "hidden" bit for all of them from the GUI. It may
be a real problem, but that is not a git problem.

A way to solve it would be to have a separate "hidedotfiles" program that
can take a folder to do that "find -name '.*' -print | xargs set-hidden"
automatically for you. It would benefit not just msysgit users but users
who want to have a little bit more POSIXy feel in their Windows life.

Shipping that program bundled with msysgit for convenience to the users is
also fine, just like you already bundle other non-git tools like dos2unix
in the package.

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Junio C Hamano wrote:

> Erik Faye-Lund <kusm...@googlemail.com> writes:
>
> > As Junio said, ".git" was hidden because it is hidden on UNIX, so we
> > _know_ that this should be hidden.
>

> A way to solve it would be to have a separate "hidedotfiles" program
> that can take a folder to do that "find -name '.*' -print | xargs
> set-hidden" automatically for you. It would benefit not just msysgit
> users but users who want to have a little bit more POSIXy feel in their
> Windows life.

It will only give a more POSIXy feel because you have to find out how to
install hooks, and it will make everything slower. Fantastic. Exactly
the user experience I want to convey to Windows users.

> Shipping that program bundled with msysgit for convenience to the users
> is also fine, just like you already bundle other non-git tools like
> dos2unix in the package.

That's why we have this core.autocrlf setting, then. Ah, okay.

What is the matter with you? I do not know what should be wrong with
allowing to hide dot files (e.g. when you get a project from Unix where
they _are_ hidden, and you want the same on Windows), but defaulting to
hiding only .git/

OTOH DDoSing the msysGit maintainer will also work. It will just make
sure that the status quo is preserved.

Ciao,
Dscho

P.S.: you managed to eat up my Git time budget yesterday.
Congratulations.

[Erik Faye-Lund]

On Sat, Jan 9, 2010 at 8:31 AM, Junio C Hamano <git...@pobox.com> wrote:
> Erik Faye-Lund <kusm...@googlemail.com> writes:
>
>> As Junio said, ".git" was hidden because it is hidden on UNIX, so we
>> _know_ that this should be hidden.
>
> That is not quite what I said (it is exactly the other way around), and
> can solicit deliberate and ridiculous misinterpretation.
>

I'm sorry, this was simply a typo (and looking at what I wrote, it
should be pretty obvious that it was). Sorry about that. What I meant
to say was this:

As Junio said, the ".git"-name was chosen because it is hidden on

UNIX, so we _know_ that this should be hidden.

--
Erik "kusma" Faye-Lund

[Erik Faye-Lund]

On Sat, Jan 9, 2010 at 12:00 PM, Johannes Schindelin
<Johannes....@gmx.de> wrote:
> Hi,
>
> On Fri, 8 Jan 2010, Junio C Hamano wrote:
>
>> Erik Faye-Lund <kusm...@googlemail.com> writes:
>>
>> > As Junio said, ".git" was hidden because it is hidden on UNIX, so we
>> > _know_ that this should be hidden.
>>
>> A way to solve it would be to have a separate "hidedotfiles" program
>> that can take a folder to do that "find -name '.*' -print | xargs
>> set-hidden" automatically for you. It would benefit not just msysgit
>> users but users who want to have a little bit more POSIXy feel in their
>> Windows life.
>
> It will only give a more POSIXy feel because you have to find out how to
> install hooks, and it will make everything slower.  Fantastic.  Exactly
> the user experience I want to convey to Windows users.
>

So your argument here is that we can do this better than an external
tool? I guess I can buy that...

But every feature has it's price in maintainability, so I think we
should ask ourselves this: is the end-user desire for this common
enough to justify this? I'm not trying to say it's not, I simply do
not know how many unix-y repos out there have dot-files that needs to
be hidden.

>> Shipping that program bundled with msysgit for convenience to the users
>> is also fine, just like you already bundle other non-git tools like
>> dos2unix in the package.
>
> That's why we have this core.autocrlf setting, then.  Ah, okay.
>

I think core.autocrlf is a bit different, because it's an issue that
clearly causes too much grief. But point taken.

> What is the matter with you?  I do not know what should be wrong with
> allowing to hide dot files (e.g. when you get a project from Unix where
> they _are_ hidden, and you want the same on Windows), but defaulting to
> hiding only .git/

I'm not personally opposing adding the feature, I'm just trying to
understand WHY we should.

> OTOH DDoSing the msysGit maintainer will also work.  It will just make
> sure that the status quo is preserved.
>
> Ciao,
> Dscho
>
> P.S.: you managed to eat up my Git time budget yesterday.
> Congratulations.

Sorry about that. FWIW, I'm fine with having my patch applied as-is.

--
Erik "kusma" Faye-Lund

[Junio C Hamano]

Johannes Schindelin <Johannes....@gmx.de> writes:

> It will only give a more POSIXy feel because you have to find out how to
> install hooks, and it will make everything slower. Fantastic. Exactly
> the user experience I want to convey to Windows users.

So msysgit is not about more "native" Windows port but about giving POSIXy
feel to the end users? That is quite different from my understanding of
why it was created in the first place as a counterpart to Cygwin port.

>> Shipping that program bundled with msysgit for convenience to the users
>> is also fine, just like you already bundle other non-git tools like
>> dos2unix in the package.
>
> That's why we have this core.autocrlf setting, then. Ah, okay.

Don't be ridiculous. core.autocrlf is all about protecting Windiws users
from those pesky Unix folks in the project who have tendency to put blobs
in the project without necessary CR at the end of the line, and without
it, will cause the checked out text files not to comform the platform
convention.

IOW, it is to make msysgit behave as a better Windows citizen, comforming
to the platform convention and giving end user experience more consistent
with other tools on Windows.

Hiding dot files on Windows goes exactly the opposite way.

> What is the matter with you? I do not know what should be wrong with
> allowing to hide dot files (e.g. when you get a project from Unix where
> they _are_ hidden, and you want the same on Windows), but defaulting to
> hiding only .git/

What is the matter with YOU? I personally don't have any stake in Windows
port nor its user experience very much, but it feels like I am the one
defending the Windows users' right and experience from you in this thread.

Maybe it is just that you don't want to admit you were wrong when you
already know you were, and still want to have the final word. To save us
from wasting time, I won't comment on this topic anymore, even though I am
sure you will fire another, final message in reply to this one.

> P.S.: you managed to eat up my Git time budget yesterday.
> Congratulations.

Same to you, as you did mine.

[Johannes Schindelin]

Hi,

On Fri, 8 Jan 2010, Erik Faye-Lund wrote:

> Ping, what's the status here? I'd expect to see this included in Dscho's
> or Hannes' repo by now, but I cant find it...

I fixed your patch (it disrespected the global config setting, so that it
always used the default path). As Junio's comments were not convincing, I
committed and pushed the fixed patch.

Ciao,
Dscho

[Johannes Schindelin]

Hi Hannes,

On Fri, 8 Jan 2010, Johannes Sixt wrote:

> On Freitag, 8. Januar 2010, Johannes Schindelin wrote:
> > On Fri, 8 Jan 2010, Junio C Hamano wrote:
> > > In other words, the final goal never is "We should hide all
> > > dotfiles".
> >
> > The whole point of adding a file with a dot in the beginning is to
> > hide it by default.
>
> Not so on Windows.

That is true for Windows-specific projects (although I never encountered
any project adding dot files except when imitating the Unix convention).
I fully acknowledge this, which is the reason why I asked for dotGitOnly
to be the default (which wish kusmabite granted).

We also try to support cross-platform projects, though, which is why I
insist to support the imitation of the Unix convention, if
core.hideDotFiles is true. This is not the default, which is why I do not
understand why a monstrous thread that used up both Junio's and my Git
time budget -- without any benefit.

And finally, if you want the default to be what it used to be, you can
switch the special handling of dot files off.

I hope that you agree that this way (and with minimal code changes), we
support a wide range of projects. If you do not agree, I am very sorry.

Ciao,
Dscho

[Johannes Schindelin]

Hi,

On Sat, 9 Jan 2010, Johannes Schindelin wrote:

> On Fri, 8 Jan 2010, Erik Faye-Lund wrote:
>
> > Ping, what's the status here? I'd expect to see this included in
> > Dscho's or Hannes' repo by now, but I cant find it...
>
> I fixed your patch (it disrespected the global config setting, so that
> it always used the default path).

Now that we have that setting, I think we should work on the problem that
ATM it is impossible to set core.hideDotFiles (or for that matter,
core.autoCRLF) when cloning, except by the "git clone -n ... && cd ... &&
git config ... && git checkout -t origin/HEAD" dance (I do not even know
if the last Git call works or not).

So this is the way I would like it to go:

- add a function to parse "--config key=value" into a string list,

- add a function to pump the string list through a given config function
such as git_default_config(),

- use both functions in both git init and git clone, and

- add a few convenience shortcuts such as --crlf, --hide-dot-files, etc

Unfortunately, for technical reasons it is not possible to provide "git
--config ... <cmd>", because the config settings would be overridden by
later parsings of the config files instead of the other way round.

Ciao,
Dscho