From: Junio C Hamano <gitster@pobox.com>
To: "Reece Dunn" <msclrhd@googlemail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] File system difference handling in git
Date: Tue, 22 Jan 2008 02:24:07 -0800 [thread overview]
Message-ID: <7vtzl6qhtk.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <3f4fd2640801220121w60cb9a69u8519a7ceb81d3414@mail.gmail.com> (Reece Dunn's message of "Tue, 22 Jan 2008 09:21:02 +0000")
"Reece Dunn" <msclrhd@googlemail.com> writes:
> 1. File name representation
>
> For Linux file systems ...
> Therefore, you have:
>
> os_to_git_path( const NATIVECHAR * ospath, strbuf * gitpath );
> git_to_os_path( const char * gitpath, const NATIVECHAR * ospath, int oslen );
It is not that simple, I am afraid. Legacy encodings can be
used in pathnames. With bog-standard traditional UNIX pathname
semantics, all pathnames are sequences of non-NUL, non-slash
bytes, separated with slashes, so if you do not allow choices
(which is a very sensible ideal world scenario), you can declare
that the "git" encoding is UTF-8 and always check things out
as-is.
But if you want a project ("git" in your above parlance) to be
checked out in two repositories, one with legacy and the other
with UTF-8, you cannot just say os_to_git/git_to_os. You would
need a bit more information from the repository owners what
encodings are suitable. So your os_to_git()/git_to_os() will
not be an identity function even on Linux to support such.
I used to have a data directory on my Linux box with EUC-JP
pathname and exported as an SMB share to my wife's Windows box,
telling samba to transliterate to whatever encoding the other
end liked. I did not want to have the pathname on the Linux end
in UTF-8 because I did not have enough energey to update my
Emacs configuration to grok Japanese in UTF-8 (even though I
finally bit the bullet and switched to UTF-8 on the Linux side
recently).
I know, this is painful. Real life hurts. Even on Linux,
not everybody can live in UTF-8-only world.
> 2. Case (in)sensitivity
>
> Here, you have the following cases:
> ...
> 3. git says that the files are different, but the filesystem says
> that the files are the same.
>
> Allow the move, updating the git directory tree only.
Sorry, I cannot really tell what you are talking about. You
seem to imply, with "Allow the move", that you are describing a
scenario that involves a move of one existing file to another,
but it is not clear. E.g. did you mean, by 3, "When the user
says 'move a b', and if git says a and b are different but if
the filesystem says a and b are the same, then..."?
next prev parent reply other threads:[~2008-01-22 10:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-22 9:21 [RFC] File system difference handling in git Reece Dunn
2008-01-22 10:24 ` Junio C Hamano [this message]
2008-01-22 10:52 ` Reece Dunn
2008-01-22 17:44 ` Steffen Prohaska
2008-01-22 20:54 ` Jonathan del Strother
2008-01-22 16:56 ` Linus Torvalds
2008-01-22 20:21 ` David Kastrup
2008-01-22 21:32 ` Linus Torvalds
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=7vtzl6qhtk.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=msclrhd@googlemail.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