Re: Issue 288 in msysgit: git init should make .git directory hidden

[msy...@googlecode.com]

Comment #12 on issue 288 by Hades32: git init should make .git directory
hidden
http://code.google.com/p/msysgit/issues/detail?id=288

I like to see my ".git" folder, but setting core.hideDotFiles to false
didn't bring
the old behavior back :(

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[msy...@googlecode.com]

Comment #13 on issue 288 by jopie64: git init should make .git directory
hidden
http://code.google.com/p/msysgit/issues/detail?id=288

Hi,

Did you set that option globally? (git config --global core.hideDotFiles
false)
It does not unhide the .git-dir when you set that option afterwards. So for
the .git-dir not to be hidden,
the option has to be set globally.

[msy...@googlecode.com]

Comment #14 on issue 288 by matthiasmueller75: git init should make .git

directory hidden
http://code.google.com/p/msysgit/issues/detail?id=288

Hi,

Hiding the .git folder and the .git* configuration files is one thing, but
hiding all
files starting with a dot (as you do now) is something completely different
and if
you ask me a bug.

As long as you are modifying the visibility of the data/configuration files
that
belong to the git product it's ok. But now are you changing the visibility
of files
which belong to the users projects and that's never going to be ok. If I
have files
in my project which start with a dot (and that's in fact the case,
otherwise I would
have noticed) I DONT want git start hiding them!
And the simple reason for that is that my development environment doesn't
like/see
hidden files and because of that I have to spent time which I don't have
enough of to
find out about what has happened and to decide how to fix that (using
core.hideDotFiles or better not using dot-files at all in order to prevent
me
spending even more time to explain problem and solution to the other team
members).

[msy...@googlecode.com]

Comment #15 on issue 288 by matthiasmueller75: git init should make .git

directory hidden
http://code.google.com/p/msysgit/issues/detail?id=288

Hi,

Hiding the .git folder and the .git* configuration files is one thing, but
hiding all
files starting with a dot (as you do now) is something completely different
and if
you ask me a bug.

As long as you are modifying the visibility of the data/configuration files
that
belong to the git product it's ok. But now are you changing the visibility
of files
which belong to the users projects and that's never going to be ok. If I
have files
in my project which start with a dot (and that's in fact the case,
otherwise I

wouldn'thave noticed) I DONT want git start hiding them!

[msy...@googlecode.com]

Comment #16 on issue 288 by kusmabite: git init should make .git directory
hidden
http://code.google.com/p/msysgit/issues/detail?id=288

matthiasmueller75: We didn't ask you - it's not a bug. You don't agree that
it's a
good feature, but I can assure you it was certainly made intentionally

First of all, this convention was borrowed from Unix, where all files
starting with a
dot is invisible by default - so why is it all of a sudden "never going to
be ok" to
do it on Windows (with an option to disable it, might I add) when it's
always done on
Unix?

Second, you're putting the blame at the wrong place - if your development
environment
can't handle hidden files, then it's the one that is broken (IMO). And
again, we DO
have a work-around - core.hideDotFiles. It's not US "wasting" your time,
it's the
ones who made your development environment.

Anyway, comments like these (that doesn't provide any insight to the issue
itself,
only frustration) are better to post on the mailing-list than on the
issue-tracker.

[msy...@googlecode.com]

Comment #17 on issue 288 by johannes.schindelin: git init should make .git
directory hidden
http://code.google.com/p/msysgit/issues/detail?id=288

I agree with kusmabite, and will therefore delete all the comments that
fall into the
category "certain to frustrate the developers, no other benefit".

[Anthony W. Youngman]

In message
<15-3335958013325811970-1463350626600685498-msysgit=googlecode.com@google
code.com>, msy...@googlecode.com writes

>
>Comment #15 on issue 288 by matthiasmueller75: git init should make
>.git directory hidden
>http://code.google.com/p/msysgit/issues/detail?id=288
>
>Hi,
>
>Hiding the .git folder and the .git* configuration files is one thing,
>but hiding all
>files starting with a dot (as you do now) is something completely
>different and if
>you ask me a bug.

Actually, it's not. It's actually *standard* behaviour across unix
systems. So git is merely applying *standard* behaviour that you're
unfamiliar with. Okay, if it's doing it to your files, then it's a bit
of a surprise, but if you move your project to nix (I guess it's not
there at the moment :-) all those files would vanish there.

>
>As long as you are modifying the visibility of the data/configuration
>files that
>belong to the git product it's ok. But now are you changing the
>visibility of files
>which belong to the users projects and that's never going to be ok. If
>I have files
>in my project which start with a dot (and that's in fact the case,
>otherwise I
>wouldn'thave noticed) I DONT want git start hiding them!

What environment are you on, then! I may have got it wrong (or, more
likely, MS has changed the behaviour), but I understood file names
*couldn't* begin with a dot on windows because it assumed the dot
signified the extension and the file didn't have a root name ...

(Actually, MS must have changed the behaviour, otherwise we wouldn't
have .git :-)

Cheers,
Wol
--
Anthony W. Youngman - ant...@thewolery.demon.co.uk

[Junio C Hamano]

msy...@googlecode.com writes:

> Comment #16 on issue 288 by kusmabite: git init should make .git
> directory hidden http://code.google.com/p/msysgit/issues/detail?id=288
>
> matthiasmueller75: We didn't ask you - it's not a bug. You don't agree
> that it's a good feature, but I can assure you it was certainly made
> intentionally
>
> First of all, this convention was borrowed from Unix, where all files
> starting with a dot is invisible by default - so why is it all of a
> sudden "never going to be ok" to do it on Windows (with an option to
> disable it, might I add) when it's always done on Unix?
>
> Second, you're putting the blame at the wrong place - if your
> development environment can't handle hidden files, then it's the one
> that is broken (IMO). And again, we DO have a work-around -
> core.hideDotFiles. It's not US "wasting" your time, it's the ones who
> made your development environment.

It may have been done intentionally, but this makes me
suspect that it was a bad decision.

I am not sure that this statement

'ls' on Unix by default does not show .gitignore in its
output; you have to ask for 'ls -a' to see it.

should logically lead to

hence we mark .gitigore hidden on Windows.

For people who live in the command line world, it literally
is just a matter of three extra keystrokes " -a" (and you
can even alias "ls" to "ls -A"). I don't know if you can
equally easily defeat the "hidden-ness" of a file in the
Windows world per-invocation basis. Can you?

If there isn't an easy way to do so, then "this was a
convention borrowed from Unix" argument does not hold water.
"We wanted to borrow the convention from Unix but couldn't
do a good job due to platform limitations" may only hurt
Windows users without giving real benefit of the convention
Unix users enjoy.

When I say "platform limitations" I don't necessarily mean
to dis Windows. The native conventions used over there may
be different from Unix conventions, and some development
tools (like the one Matthias seems to be having trouble
with) that follow the Windows conventions may not work well
with the way you emulate "ls without -a hides .gitignore"
on Unix with "mark files hidden" on Windows.

That brings us to your second point. That way of emulating
dotfile semantics was chosen by msysgit, not by Windows nor
the development environment Matthias uses. It looks an
msysgit issue to me.

Would it be an option not to emulate "'.gitignore' is not
shown by ls without -a" on Windows at all? After all, it
doesn't look like something msysgit _should_ be solving to
begin with. Why should files starting with a dot that
happen to be under source control by git be hidden, while
the ones inside "C:\My Documents\" that is not under git are
not hidden?

[Erik Faye-Lund]

On Tue, Dec 15, 2009 at 9:57 PM, Junio C Hamano <git...@pobox.com> wrote:
> msy...@googlecode.com writes:
>
>> Comment #16 on issue 288 by kusmabite: git init should make .git
>> directory hidden http://code.google.com/p/msysgit/issues/detail?id=288
>>
>> matthiasmueller75: We didn't ask you - it's not a bug. You don't agree
>> that it's a good feature, but I can assure you it was certainly made
>> intentionally
>>
>> First of all, this convention was borrowed from Unix, where all files
>> starting with a dot is invisible by default - so why is it all of a
>> sudden "never going to be ok" to do it on Windows (with an option to
>> disable it, might I add) when it's always done on Unix?
>>
>> Second, you're putting the blame at the wrong place - if your
>> development environment can't handle hidden files, then it's the one
>> that is broken (IMO). And again, we DO have a work-around -
>> core.hideDotFiles. It's not US "wasting" your time, it's the ones who
>> made your development environment.
>
> It may have been done intentionally, but this makes me
> suspect that it was a bad decision.
>

I'm not completely convinced making hiding dotfiles the default was
the best solution either, but complaints came from the other camp
before this change as well. I don't think this is something that
everyone will agree on, ever.

FWIW, SVN hides the .svn-folders, but not other dotfiles. Perhaps this
is a good thing to follow as a default?

> I am not sure that this statement
>
>    'ls' on Unix by default does not show .gitignore in its
>    output; you have to ask for 'ls -a' to see it.
>
> should logically lead to
>
>    hence we mark .gitigore hidden on Windows.
>

No, but it doesn't limit itself to 'ls' - at least also Nautilus does this.

> For people who live in the command line world, it literally
> is just a matter of three extra keystrokes " -a" (and you
> can even alias "ls" to "ls -A").  I don't know if you can
> equally easily defeat the "hidden-ness" of a file in the
> Windows world per-invocation basis.  Can you?
>

Yes there is, "dir /h". It does the exact same thing as "ls -a" does.
I don't think e.g Nautilus has a simple way to show hidden files per
invocation either, but I might be wrong.

I'd also like to argue that any sane developer has "show hidden
files"-enabled... but then again, I write code with visible
white-space enabled. Perhaps I'm just a control-freak.

> If there isn't an easy way to do so, then "this was a
> convention borrowed from Unix" argument does not hold water.
> "We wanted to borrow the convention from Unix but couldn't
> do a good job due to platform limitations" may only hurt
> Windows users without giving real benefit of the convention
> Unix users enjoy.
>
> When I say "platform limitations" I don't necessarily mean
> to dis Windows.  The native conventions used over there may
> be different from Unix conventions, and some development
> tools (like the one Matthias seems to be having trouble
> with) that follow the Windows conventions may not work well
> with the way you emulate "ls without -a hides .gitignore"
> on Unix with "mark files hidden" on Windows.
>
> That brings us to your second point.  That way of emulating
> dotfile semantics was chosen by msysgit, not by Windows nor
> the development environment Matthias uses.  It looks an
> msysgit issue to me.
>

There isn't any global "hidden files are special in any other way than
not visible from the user interface (unless overridden)"-semantic in
Windows, so I'm still thinking this is very much a development
environment issue. I'm assuming this is about the
Eclipse-won't-write-files-that-are-hidden crap that was reported just
a couple of days ago. Sorry, but the hidden flag and the read-only
flag is not the same thing in Windows - this one is on Eclipse's
hands. We have a work-around, so I'm not loosing much sleep about it,
at least not until anyone comes up with a compelling argument.

See http://msdn.microsoft.com/en-us/library/ee332330(VS.85).aspx for
documentation on the attributes.

Of course, if I'm misunderstanding the issue and this isn't related to
Eclipse's brokenness, I'm sorry.

> Would it be an option not to emulate "'.gitignore' is not
> shown by ls without -a" on Windows at all?  After all, it
> doesn't look like something msysgit _should_ be solving to
> begin with.  Why should files starting with a dot that
> happen to be under source control by git be hidden, while
> the ones inside "C:\My Documents\" that is not under git are
> not hidden?
>

Personally, I'm not a big user of this feature - I have the "show
hidden files"-option enabled on all my machines. However, I do like
the ".git-folder's labels are grey instead of black"-effect in
explorer, as it makes easier for me to filter out what not to look at.

I'd say adding a "hide .git-folder" (and possibly also .gitignore etc)
setting to core.hidedotfiles and making that the new default would
make the most sense. That way, novice users won't start messing around
with the internal git-data structures (unless he really knows what
he's doing), and users get to see all their version-controlled files.
As a nice bonus for Eclipse-users, they won't have to learn how to
patch Eclipse in order to get real work done.

I'm guessing the ".git"-folder name was chosen because it's hidden in
Unix, right? At least the .git-folder is supposed to be completely
maintained by git (not that it really is in practice, at least not
yet), so it makes sense to me to hide it by default.

Perhaps this is a sensible middle-ground, hm?

--
Erik "kusma" Faye-Lund

[Junio C Hamano]

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

> I'm not completely convinced making hiding dotfiles the default was
> the best solution either, but complaints came from the other camp
> before this change as well. I don't think this is something that
> everyone will agree on, ever.
>
> FWIW, SVN hides the .svn-folders, but not other dotfiles. Perhaps this
> is a good thing to follow as a default?

I think the original #288 was about ".git" (and not "dotfiles in
general"), and I think it is probably sensible to hide it. Ordinary users
have no business mucking files in there (including e.g. "purging
.git/rr-cache/* file to forget a faulty resolution" --- that is merely a
lack of "git rerere forget" we should fix independently).

On the other hand, .gitignore should be handled exactly the same way as
your hello.c and hello.h by git, as they are both tracked contents.

It is a separate matter if you tell your Exporer or Tortoise to show *.c
files and *.h files in different colors and in that context you may want
to color .gitignore and other dot-files differently as well, but my point
is that distinction is outside the realm of SCM at that point.

>> I am not sure that this statement
>>
>> 'ls' on Unix by default does not show .gitignore in its
>> output; you have to ask for 'ls -a' to see it.
>>
>> should logically lead to
>>
>> hence we mark .gitigore hidden on Windows.
>
> No, but it doesn't limit itself to 'ls' - at least also Nautilus does this.

But my point still stands, as in Nautilus Ctrl-H is just one keystroke
away, isn't it?. Even if Explorer may have a similar short-cut way to
toggle it, is the same trick usable by whatever tool Matthias was having
trouble with?

Also in Unix world, glob(3) is aware of it so shell automatically gives a
similar "semi-hide" semantics ("ls *" vs "ls .* *"), but again it is only
three keystrokes away to defeat it.

In any case, my point is that "dotfiles are kept outside of the view by
many tools by default but you can access them with equal ease as non
dotfiles when you need to" may be very different from a simple-boolean
"dotfiles are hidden, others are not hidden", and the result may be
unusable if you only implement "kept outside of the view" without giving
users "equal ease as non dotfiles when you need to".

I don't do/use Windows, so I am not a good judge to tell if you gave users
"equal ease" or not. That is something Windows/msysgit people to decide.

If the answer is "Yes--it is just as easy for Unix users", then it would
be great. Otherwise, you may want to limit the hiding to ".git" and
nothing else.

[Erik Faye-Lund]

On Tue, Dec 15, 2009 at 11:49 PM, Junio C Hamano <git...@pobox.com> wrote:
> Erik Faye-Lund <kusm...@googlemail.com> writes:
>
>> I'm not completely convinced making hiding dotfiles the default was
>> the best solution either, but complaints came from the other camp
>> before this change as well. I don't think this is something that
>> everyone will agree on, ever.
>>
>> FWIW, SVN hides the .svn-folders, but not other dotfiles. Perhaps this
>> is a good thing to follow as a default?
>
> I think the original #288 was about ".git" (and not "dotfiles in
> general"), and I think it is probably sensible to hide it.  Ordinary users
> have no business mucking files in there (including e.g. "purging
> .git/rr-cache/* file to forget a faulty resolution" --- that is merely a
> lack of "git rerere forget" we should fix independently).
>

I 100% agree. Perhaps we shouldn't even have an option to disable this
functionality?

There are some hacks to get a hotkey for this, but those feel quite
hacky. So I tend to agree with you - thanks for keeping me sane.

Here's a quick stab at forcing .git to be hidden (it'll also trigger
for other directories called ".git" in the work-tree -- dunno if this
is usually possible), while setting the default for core.hidedotfiles
to disabled.

diff --git a/compat/mingw.c b/compat/mingw.c
index 2424380..9845bbf 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -134,14 +134,14 @@ 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) {
/*
* In Windows a file or dir starting with a dot is not
* automatically hidden. So lets mark it as hidden when
* such a directory is created.
*/
const char *start = basename((char*)path);
- if (*start == '.')
+ if (!strcmp(start, ".git") || (*start == '.' && hide_dotfiles))
return make_hidden(path);
}
return ret;
diff --git a/environment.c b/environment.c
index ea1abbf..a230179 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;
+int hide_dotfiles = 0;

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

--
Erik "kusma" Faye-Lund

[Johannes Schindelin]

Hi,

On Tue, 15 Dec 2009, Anthony W. Youngman wrote:

> In message
> <15-3335958013325811970-1463350626600685498-msysgit=googlecode.com@google
> code.com>, msy...@googlecode.com writes
> >
> >Comment #15 on issue 288 by matthiasmueller75: git init should make .git
> >directory hidden

Maybe you wanted to Cc: matthiasmueller75?

Ciao,
Dscho

[Johannes Schindelin]

Hi,

On Wed, 16 Dec 2009, Erik Faye-Lund wrote:

> On Tue, Dec 15, 2009 at 11:49 PM, Junio C Hamano <git...@pobox.com> wrote:
> > Erik Faye-Lund <kusm...@googlemail.com> writes:
> >
> >> I'm not completely convinced making hiding dotfiles the default was
> >> the best solution either, but complaints came from the other camp
> >> before this change as well. I don't think this is something that
> >> everyone will agree on, ever.
> >>
> >> FWIW, SVN hides the .svn-folders, but not other dotfiles. Perhaps
> >> this is a good thing to follow as a default?
> >
> > I think the original #288 was about ".git" (and not "dotfiles in
> > general"), and I think it is probably sensible to hide it. �Ordinary
> > users have no business mucking files in there (including e.g. "purging
> > .git/rr-cache/* file to forget a faulty resolution" --- that is merely
> > a lack of "git rerere forget" we should fix independently).
> >
>
> I 100% agree. Perhaps we shouldn't even have an option to disable this
> functionality?

I want to have an option to prevent hiding .git. Maybe I haven't repeated
myself often enough? A patch adding support for "core.hideDotFiles =
dotGitOnly" would be welcome, and should actually be not all that hard,
given that your patch does half of it.

Ciao,
Dscho

[Junio C Hamano]

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

> On Tue, Dec 15, 2009 at 11:49 PM, Junio C Hamano <git...@pobox.com> wrote:
>> Erik Faye-Lund <kusm...@googlemail.com> writes:
>>
>>> I'm not completely convinced making hiding dotfiles the default was
>>> the best solution either, but complaints came from the other camp
>>> before this change as well. I don't think this is something that
>>> everyone will agree on, ever.
>>>
>>> FWIW, SVN hides the .svn-folders, but not other dotfiles. Perhaps this
>>> is a good thing to follow as a default?
>>
>> I think the original #288 was about ".git" (and not "dotfiles in
>> general"), and I think it is probably sensible to hide it.  Ordinary users
>> have no business mucking files in there (including e.g. "purging
>> .git/rr-cache/* file to forget a faulty resolution" --- that is merely a
>> lack of "git rerere forget" we should fix independently).
>
> I 100% agree. Perhaps we shouldn't even have an option to disable this
> functionality?

I wouldn't go that far.

> Here's a quick stab at forcing .git to be hidden (it'll also trigger
> for other directories called ".git" in the work-tree -- dunno if this
> is usually possible), while setting the default for core.hidedotfiles
> to disabled.

I wouldn't mind an extra call to

mark_as_git_dir(dir);

added immediately after the first "safe_create_dir()" in init_db(), where
mark_as_git_dir() can be (re-)defined for each platform's convenience.
Maybe ACL-minded people might want to define an implementation that does
something special in there even on Unix.

And on Windows, unless the user wants to decline the default of hiding it,
it would mark the directory hidden, or whatever.

[msy...@googlecode.com]

Comment #18 on issue 288 by michael.laccetti: git init should make .git
directory hidden
http://code.google.com/p/msysgit/issues/detail?id=288

How can we disable this functionality for folders/files that aren't .git?
This issue
causes problems with Eclipse dot files that are hidden.

[msy...@googlecode.com]

Comment #19 on issue 288 by kusmabite: git init should make .git directory
hidden
http://code.google.com/p/msysgit/issues/detail?id=288

You can set core.hidedotfiles to "false" in your repo, delete your working
copy, and
run "git reset --hard". Since the .git-folder is already created with the
hidden-flag,
it won't lose it.

[msy...@googlecode.com]

Comment #20 on issue 288 by daniel.zeiter: git init should make .git
directory hidden
http://code.google.com/p/msysgit/issues/detail?id=288

As the post before says, hiding all "."-Files is a really bad idea, because
many
Windows tools treat hidden files as readonly. For example Eclipse
stores .project and
.classpath files in the workspace and can not edit them anymore, because
there hidden.

Please change this fix that at most the .git directory is hidden.

[msy...@googlecode.com]

Comment #21 on issue 288 by kusmabite: git init should make .git directory
hidden
http://code.google.com/p/msysgit/issues/detail?id=288

daniel: Are you sure _many_ Windows tools does this? I've ONLY seen this
with
Eclipse, and it's clearly a bug.

That being said, I agree with you that we shouldn't hide all dotfiles by
default - in
fact, I already sent a patch addressing this issue:
http://groups.google.com/group/msysgit/browse_thread/thread/2480ba1823dc169b/cb0a4330
85b3192d

Next time, please take the time to search the mailing list first.