[Tfug] Version Control

[Yan]

Hello,

 Also, I was wrong before: git does ship with built-in GUI tools, git-gui (
>> http://git-scm.com/docs/git-**gui <http://git-scm.com/docs/git-gui>) and
>> gitk (http://git-scm.com/docs/gitk)**,
>> written by the git project.
>>
>
> Thanks!  So, are you nominating this/these as the "official"
> candidate(s) that I should use to represent git in my comparison?
>

Well, I am not involved in the git project or anything in any way, so I
can't really speak for them, but gitk is what I was pointed to when I
needed to make sense of something through a GUI, so that's what I'd point
someone to if they were in that situation as well :-). At the very least,
they are the GUI tools that are maintained by the GIT project itself. There
are plenty of capable, regularly-updated third-party GUIs, but as you've
pointed out, there is less guarantee that such third-party GUIs will
continue being developed.

As for the automatically figuring out what diff tool to use thing, git can
definitely use file extensions (as shown here:
http://lars-tesmer.com/blog/2010/09/20/git---how-to-get-better-diffs-for-images/)
for automatic file type identification. As you've said, you'd prefer a
fully automated approach (so you can check in jpegs as "blah.ps" and still
have git realize they're jpegs). I've never really had the need for that,
and don't know exactly how one would go about accomplishing such a thing,
but there is at least part of a chapter of the git book dedicated to
diffing in general (http://git-scm.com/book/ch7-2.html), so you could read
up on it if it's critically important. A quick search yielded that the
initial setup will likely contain a decent amount of manual work. One
solution would be to set up a default differ (as in here:
http://jeetworks.org/node/90) that would determine the filetypes involved
using "file" or something and then call the appropriate application.
This'll achieve the behavior you want, but now you're stuck maintaining
your diffing script (which may or may not be a headache).

At some point, you've mentioned ad-hoc text files littering the heirarchy.
Git's a bit better than CVS and SVN in this sense, as it at least keeps all
of its stuff in the project's root directory (mostly in .git/, but custom
configuration such as submodules, per-project diff configs, and so forth
spill out into other dotfiles in this directory). This, however, has the
notable downside of being unable to check out a subdirectory of a
repository (like you can in SVN), so you should be aware of that. The stuff
*inside* the .git directory is described in the git book (
http://git-scm.com/book/en/Git-Internals) if you want to interface with it.
I think the general consensus is that if you are doing that, you're doing
something wrong.

An interesting (though probably not relevant) thing is that Perforce
supports git clients.

Finally, git is not perfect (examples:
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/,
http://www.forouzani.com/disadvantages-of-git.html). I feel it's better
than the other things I've used (significant point: I haven't used
Mercurial to any great extent), and using a commercial application (like
Perforce) for something so integral to your workflow seems really weird to
me, but I guess some people do it. Personally, I wouldn't trust Perforce to
stay around (for example, Google has a stunning history of axing products
after purchasing their parent company).

- Yan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20130329/f2da473c/attachment-0002.html>