Some devs here started to use egit on windows, and since egit is not
complete yet, occasionally^Wregularly use msysgit for
rebase/stash/you-name-it.

This revealed a strange problem that took some time figuring out,
where eclipse refused to write to .classpath or .project, just saying
"could not write", while other apps had no problem editing the same
files.

In the end, the problem is that the dotfiles had the "hidden" bit set,
and that for some reason eclipse does not allow to write to hidden
files - and that the one (re)setting the "hidden" bit over and over
again is msysgit, whenever it checkouts such a dotfile - surely to
emulate the unix behaviour of hiding dotfiles by default.

I'm not sure who's at fault here - namely, I can't see any valid
reason for eclipse to refuse such writes, but I am not sure it is a
good reason for msysgit would set the hidden bit either.  In either
case, even if only for the short term, I think msysgit should ensure
that this bit does not get set (possibly circumventing any magic msys
would do behind its back).

Best regards,
-- 
Yann
--

[ message continues ]

Setting the config option "core.hidedotfiles" to "false" should
prevent this from happening.

-- 
Erik "kusma" Faye-Lund
--

[ message continues ]

why isn't this the default?

I also experienced this change in behaviour and I thought we would
strive to keep the experience the same.
--

[ message continues ]

You can follow the discussion here:
http://code.google.com/p/msysgit/issues/detail?id=288

I believe the reason is something like "because someone suggested it,
and no one disagreed". Do you have a good argument why it shouldn't be
the default (other than "it's a change", because changing it back now
would also be a change)?

-- 
Erik "kusma" Faye-Lund
--

[ message continues ]

Depending on the opinion of the Eclipse guys on this issue about
"writing to hidden files only says 'could not write'", which arguably
could be seen as a bug on their side, we can see changing this
behaviour back to the default on the msysgit side as either a
(possibly temporary) workaround for a known eclipse bug, or as getting
again interoperable with egit.

Note that I did not get time yet to fully investigate the eclipse
status on the issue.

Best regards,
-- 
Yann
--

[ message continues ]

Dot-files on unix are considered hidden. It's the only way files are 
hidden there. Not so on Windows. Dot-files are just like any normal 
file, and you need to mark a file hidden.

So, the logic of egit, that *actually* hidden files should not be 
written to, but dot-files should, seems to me to be a bug in egit. 
There should be no reason why egit shouldn't be able to write to any 
file, pending permissions. I'd say file a bug report with egit.

--
.marius
--

[ message continues ]

Actually it is not egit who is unable to write to the file, but
eclipse itself, and I do tend to think it is a bug in eclipse.  But
now, even if we can convince the eclipse guys that it is a bug, it
will be some time before a new release with this bug fixed gets
published.

So IMHO it would makes sense, for the sake of usability, to not
activate the "hide dotfiles" feature by default.  It is easier for
someone seeing unwanted dotfiles to find the switch to hide them, than
for someone getting a "could not write" message from eclipse to
understand that there is a seemingly-unrelate switch for msysgit to
avoid this situation.

But maybe the situation is not so clear.  That "hide dotfiles" was
implemented so that ".git" at first, and then ".git*" files do not
clutter the view of the project.  But then, if a git repo has other
dotfiles, those are really *part of* the versionned stuff, so I do not
see why those should be hidden at all.  After all, the .project,
.classpath, and other eclipse project files have that name on windows
too, and it will indeed *confuse* people to get them hidden.

So should we have 2 classes of dotfiles, those "private to git", and
the others, one class being hidden while the others are not ?  I am
not sure at all this would be a good idea either.  Or maybe we should
only get .git hidden - after all, that one is the only real metadata
not part of the versionned stuff itself ?

Maybe we should add some sort of "core.hidedotfiles = dotgitonly"
setting, and make that the default ?  That one does not appear to
cause any problems to jgit, and eclipse itself has not business with
it, so it would IMHO make sense.

Opinions ?
--

[ message continues ]

Actually, I think it makes much more sense to put a note of the issue
in the release-notes. I don't want people to lose features because
Eclipse, an IDE I don't even use, is broken. Since Eclipse is the
culprit here, I think it's the Eclipse that should "take the hit", not
the rest of us.

This of course assumes that hidden dotfiles is a feature that people
want, which is what I assumed was the reason why it was added in the
first place. Personally I don't care about this feature, since I have

IF we were to go down this path, perhaps it would be even better to
use some sort of file-pattern or even squeeze this into gitattributes?
I guess something like ".* +hidden" should emulate the unix behaviour
(given that we add a hidden attribute). I don't think we have a global
gitattributes file though, so it'd have to be added to each repo where
the effect is desired, I guess.

-- 
Erik "kusma" Faye-Lund
--

[ message continues ]

Hi,


Actually, I think the original request was really for all the dot files, 
not just for .git.

But I can see the reasoning behind hiding only .git, which I would not 
like to make the default, though.  I would like to make Eclipse users set 
this explicitely in their /etc/gitconfig (possibly via the Git for Windows 
installer, just like the infamous -- and still broken -- core.autocrlf 
setting, if Sebastian is nice enough to make yet another page in the 
installer).

So: I would definitely take a patch implementing "core.hidedotfiles = 
dotgitonly", but would hesitate to make it the default.

Ciao,
Dscho
[ message continues ]