Disqus - Latest Comments for jnareb

Re: You keep using that word “distributed”…

jnareb — Fri, 10 Oct 2008 11:21:11 -0000

I don't think hosting your own public repository over HTTP in Git is absurdly complicated (by the way, you can host via SSH, or via git protocol using git-daemon). You should share bare repository, and "dumb" HTTP protocol requires extra info present, which is provided by git-update-server-info, and which is automated by the use of update hook.

Re: Shortcomings of Mercurial

jnareb — Sat, 08 Mar 2008 14:17:19 -0000

@ William Tanksley Jr:

Errr... I think I haven't been clear enough. With Git you can either detect merge markers in (default, you only need to enable it) pre-commit hook and refusing commit unless overriden with --no-verify.

Or you can change default file-level merge driver for some files or for all files (using combination of gitattributes and config) from "text" (which inserts diff3 -E like merge markers) to "binary" (which leaves 'our' version on disk and does not insert any merge markers).

BTW: http://git.or.cz/gitwiki/MailingList

Re: Shortcomings of Mercurial

jnareb — Fri, 07 Mar 2008 20:11:22 -0000

http://git.or.cz/gitwiki/BlogPosts see section "Portability" (Git on MacOS X).

As to why Git has so many dependencies: much of commands are written in either Perl (thus requiring Perl), or in shell scrips (thus requiring some of shell utils). Git also uses existing libraries, like libz, or libcurl, or libcrypto for things like compression, or HTTP protocol, or cryptographic hashes.

By the way, if I remember correctly, Mercurial has some of its code written in C for performance. And you have to got all those Python modules installed.

Re: Shortcomings of Mercurial

jnareb — Fri, 07 Mar 2008 15:16:49 -0000

@William Tanksley Jr:

First, when there is a merge conflict, Git leaves all three versions (base / ancestor, ours, theirs) in the index (commit staging area), and stores file with merge markers on filesystem. So you always have easy access ("git show :1:<file>" for example to get base version) to all versions.

Second, default pre-commit hook which ships with Git, and is by default installed in newly created repositories, detect merge markers in file (and also things like trailing whitespace) and refuses to make a commit if it looks like you didn't resolve a merge. You just have to enable it by making it executable ("chmod a+x .git/hooks/pre-commit"). Of course you can foce skipping verification phase if the tool misdetected merge markers with --no-verify option.

Third, you can use gitattributes to set merge driver for specified files, for example for all files, or/and you can use merge.default configuration option, choosing e.g. "binary" driver which leaves current version of file in the working dir in the case of conflicts.

BTW. why didn't you ask this question on Git mailing list or on #git channel on FreeNode? Git mailing list is open; you don't have to subscribe to post. Just make sure to specify that you'd like to get messages replied also to you, and/or read mailing list via mailing list archives or GMane NNTP (Usenet, news) interface.

Re: Shortcomings of Mercurial

jnareb — Fri, 07 Mar 2008 05:53:32 -0000

A bit of Git advocacy:

* Git handles binary files correctly (it detect binariness using algorithm used by diff and other GNU tools, but you can mark given file as binary or text using gitattributes). Binariness of file does not matter to the Git libXdiff deltaification. Git can send / generate binary patches. Unfortunately, depending on binary file and how much it repesentation change due to small underlying change, Git can fail to detect file rename or file copying (it is based on similarity score).

* From some time Git ships with its own diff3 / rcsmerge file level merge tool. It would put CVS-like conflict markers in a file which has merge conflict. There is git-mergetool helper which helps to use configured graphical merge tool kile KDiff3, Meld, Emacs emerge etc.

* Git has core.sharedRepository configuration option, with possible values being: group, all. umask, to set correct permissions for git repository files, when using repository in shared fashion. Nevertheless DSCMs are usually geared to other workflows...