27 minutes in, we learn that git doesn't track explicit renames, but
instead intuits them (as well as copies) from matching file contents.
I assume that means if you're doing a tree reorg, you really want to
commit the tree operations separately from any file modifications you
want to do to the renamed files (e.g. because you're moving Java source
and renaming the classes at the same time), or git won't be able to
tell. That might in turn result in a temporarily broken build, but
that's a minor point which you could easily plaster over with branches.
The major point is that this feels like a variation of Subversion's
mistake in tracking copies rather than renames. Randal says that if you
copy a file to three different places and then change it in one place,
you probably want to change it in the others, but my intuition says
that's a very dangerous assumption.
I'm sure this has been explored ad infinitum on the git mailing lists;
I'm kind of curious how it pans out in practice. We know that
Subversion fails miserably in merging when there have been tree
operations on either side of the merge; this is because Subversion tree
merging is based on pathnames without little regard to object movement.
git merging is (apparently) purely based on file contents without regard
to pathnames, which I would expect to have different but still sometimes
terribly wrong behavior. I could be wrong; complex merging gives me a
headache if I think about it too hard.
On a less serious note, as someone who hasn't been on a plane in years,
I've gotten really tired of "I can work on an airplane" as the poster
child for disconnected operation. I'm sure it's very important to
consultants who are jetting around the country every other week--say, to
give talks about distributed version control tools--but there are a
large class of developers who could care less whether they can work on
an airplane.
The usage model feels a bit like darcs's, where repositories are
synonymous with working copy metadata. But, if I'm remembering right, a
darcs wc/repo only covers one line of development, whereas a git wc/repo
covers many.
The "rebase" operation is an interesting generalization of "cvs
update" (in the case where you have local modifications). I'm curious
how often the idea shows up in other DVCS tools as a way of avoiding
"bushy branches" during day-to-day development. darcs, of course,
rebases *everything* so that the view from any working copy is always a
linear list of changes.
On Wed, 2007-10-31 at 09:28 -0500, Ben Collins-Sussman wrote:
> Subversion devs: there's a fabulous video up on youtube now, where
> Randal Schwartz (famous perl hacker) gives a tech-talk about GIT:
>
> http://youtube.com/watch?v=8dhZ9BXQgc4
>
> No, this isn't entirely off-topic. A number of us have discussed
> "stealing" various features from distributed version control systems,
> and this talk is really something worth digesting. Unlike the awful
> GIT talk given by Linus Torvalds earlier this year (where he spent
> lots of time cursing subversion and insulting his audience), this talk
> is all technical... no political agenda. Randal explains the
> architecture of the system, why it's cool, and how one uses it. It's
> a fascinating talk. (Well, fascinating to people who think about
> version control, I guess!)
>
> I know that everyone is focused on finishing svn 1.5 -- I just wanted
> to share this link with the community so that if you *do* find an hour
> of free time, you have something worthwhile to watch and think about.
> Put it on your iPod or something, watch it on the train. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 1 06:27:28 2007