Git development
 help / color / mirror / Atom feed
From: Yann Dirson <ydirson@linagora.com>
To: Marius Storm-Olsen <mstormo@gmail.com>
Cc: kusmabite@gmail.com, Ferry Huberts <ferry.huberts@pelagic.nl>,
	GIT ml <git@vger.kernel.org>
Subject: Re: [BUG] Bad msysgit/egit interaction over dotfiles
Date: Thu, 10 Dec 2009 09:35:14 +0100	[thread overview]
Message-ID: <20091210083514.GA5971@linagora.com> (raw)
In-Reply-To: <4B200EF5.2060606@gmail.com>

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.

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 ?

  reply	other threads:[~2009-12-14  8:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-08 13:28 [BUG] Bad msysgit/egit interaction over dotfiles Yann Dirson
2009-12-08 13:34 ` Erik Faye-Lund
2009-12-08 13:42   ` Ferry Huberts
2009-12-08 14:23     ` Erik Faye-Lund
2009-12-08 14:37       ` Yann Dirson
2009-12-09 20:56         ` Marius Storm-Olsen
2009-12-10  8:35           ` Yann Dirson [this message]
2009-12-14  9:13             ` Erik Faye-Lund
2009-12-14 11:45               ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091210083514.GA5971@linagora.com \
    --to=ydirson@linagora.com \
    --cc=ferry.huberts@pelagic.nl \
    --cc=git@vger.kernel.org \
    --cc=kusmabite@gmail.com \
    --cc=mstormo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox