On Thu, Dec 10, 2009 at 9:35 AM, Yann Dirson <ydirson@xxxxxxxxxxxx> wrote: > On Wed, Dec 09, 2009 at 09:56:21PM +0100, Marius Storm-Olsen wrote: >> Yann Dirson said the following on 08.12.2009 15:37: >> >On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote: >> >>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)? >> > >> >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. >> >> 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. > > 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. > 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 the "show hidden files"-feature turned on. > 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 ? > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html