(valid) criticisms of Git addressed (was: I am using fsvs and just found svnhome in google...)

[martin f krafft]

also sprach Juliano F. Ravasi <ml at juliano.info> [2008.08.27.0302 +0100]:
> 1. Both don't see directories. Just because a directory is empty
> doesn't mean that it doesn't exist. If I delete all files in
> a directory, it doesn't mean that that directory ceased to exist.
> Some programs don't expect this. For example, file all messages
> from your Inbox, and commit. Then you pull from the other machine,
> and your Inbox directory just disappears.

If you emptied your inbox, why keep it around? I expect the tools
I use to recreate empty directories aqs needed.

This is apart from the fact that I prefer to use IMAP for
synchronising mail, since it's a better tool (made) for the task and
can do stuff (like flags) better than a mail-agnostic tool, such as
a content tracker.

> 2. Both lack proper ways to store metadata. This is evidenced by
> the need to pollute your directories with .gitignore,
> .gitattributes and .gitmodules (for Git), and .hgignore,
> .hgbranches and .hgtags (for Mercurial). All this information is
> threated and versioned as part of the contents of the repository,
> while it should not. It is the plumbing of the VCS that gets
> exposed and mixed with the user files.

This is a very valid point and I wish Git had a metadata layer. I've
tried to bring up the issue with the developers, but they're not
interested in making Git more generic ("it's used to track the linux
kernel sources, if you use it for anything else, you are on your
own").

But keep in min that Git, Mercurial & Co. are first-generation (if
you are willing to place arch into the zeroth generation, and see
Monotone in a league of its own). We are surely going to see new
tools which pick up on these issues in the future.

There is one thing to be said in favour of in-filesystem metadata,
such as .gitattributes — conflicts in those are no different than
conflicts in content files, and all of the standard and advanced
conflict resolution mechanisms (merge drivers, git-rerere, etc.) can
be used for those just as well. Surely, this could be remedied by
exposing the metadata layer as files in the event of conflicts, but
that would be a hack in my world, and likely come with other
problems.

> In the case of Git, .gitattributes is a huge misfeature. The
> attributes stored in it are user-edited, and is not attached to
> the actual files. If you move files around, you suddenly lose your
> attributes until you fix the attributes file.

Agreed.

> 4. Git only: lack of real rename/copy support. This affects not
> only vcs-home, but also general SCM use; it is just worse for
> vcs-home. There is a much bigger likelihood of having binary files
> in your home than common source code projects (what Git was
> designed to manage). Images, text documents, spreadsheets,
> presentations, compressed files, etc... For example, you change
> a single character in an ODF document and save. You will see that
> the file is completely different binary-wise, not easy to track.

Git doesn't track the file, it tracks the content. If you make small
changes, it's likely that the two blobs will be compressed to little
more than the size of one in the store. When it comes to keeping the
association (e.g. log messages), Git uses commit history anyway to
figure this out.

> If you also rename before the commit, you just lose the
> connection, and there is nothing you can do about it.

This has not happened to me before, or well, it's not bitten me.

Do you mean something like:

+lapse:~/.tmp/cdt.VLULwrjW|master|% echo foo > testfile
fatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git add testfile
gfatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'add testfile(foo)'
Created initial commit 3ff1892: add testfile(foo)
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% echo bar >| testfile  
changes on filesystem:
 testfile |    2 +-
+lapse:~/.tmp/cdt.VLULwrjW|master|% git mv testfile someotherfile
cached/staged changes:
 someotherfile |    1 +
 testfile      |    1 -
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'moved the file to someotherfile(bar)'
Created commit 78b242f: moved the file to someotherfile(bar)
 2 files changed, 1 insertions(+), 1 deletions(-)
 create mode 100644 someotherfile
 delete mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% git log -- someotherfile 
commit 78b242f2d5df1ebe96e25e2dc6c69eb1c135cbb2
Author: martin f. krafft <madduck at madduck.net>
Date:   Wed Aug 27 13:55:37 2008 +0100

    moved the file to someotherfile(bar)

> 5. Git doesn't actually support Unicode filenames (neither does
> Mercurial). Both just store whatever the file name is in the
> filesystem directly into the repository, as just an array of
> bytes. You won't notice this unless you create files with names
> containing characters beyond the ASCII set, and use different
> encodings in different computers. This also causes problems when
> cloning your repositories to systems that are Unicode-aware (like
> Windows[1] and MacOS X[2]).

If you store the encoding along with the filename, you'll run into
a whole lewd of other issues when transcoding.

My solution to this is just to have UTF-8 everywhere. I am all too
glad to have waved goodbye to all those encoding nightmares that
were iso8859-* and ascii.

> Syncing repositories using Git or Mercurial between systems using
> different encodings is a nightmare. Git doesn't even respect LANG
> and LC_CTYPE, and expect everything (including commit messages) to
> be in UTF-8 no matter what the user have set his system to.

I think this is a feature. If we keep adding backwards-compatibility
layers to tools, we not only make them bigger, more error-prone, and
harder to maintain, but we also slow down the transition to better
times.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"'the answer to the great question...'
 'of life, the universe and everything...' said deep thought.
 'is...' said deep thought, and paused.
 'is...'
 'forty-two,' said deep thought, with infinite majesty and calm."
                                 -- hitchhiker's guide to the galaxy
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20080827/f5371fcf/attachment-0001.pgp>