On 10/31/07, Greg Hudson <ghudson@mit.edu> wrote:
>
> 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.
This is what I originally thought as well, that commits would be broken into
move/change pairs. I believe they do simple heuristics instead, most
probably like OS X's aliases - if you move a file the system will perform
some business logic to track down where it is, but if you move a new file in
its place it assumes you meant to replace the original. E.g. look at files
that were created in the same rev the one you had disappeared.
In practice, I've found tracking renames to not be worth the pain. If you
need to track copies and moves, you wind up having special commands that
have to be learned in order to do so. Without those, you can take changes to
a working copy (including new and missing files) to be intentional, and
committing becomes a snapshot operation.
The biggest complaint I have heard from users of subversion is that getting
snap-shot behavior is too error prone. Some will have Mac OS X bundles that
they wish to manage, or document directories they want to reorganize, or
attempt to do java development but don't enable an appropriate plugin. A lot
of these issues get solved with a single root .svn tracking directory, but I
bring it up for one reason:
Its important to not make getting work committed hard.
Indeed, this is my opinion, but I believe its better to make complex merges
require more education than the complicate up commits.
Maybe this means the person who reorganizes the class layout of a widely
followed java project runs a few commands or runs a special IDE plugin or
set of commands so that metadata on moves is more directly indicated to
tools. Maybe this means the same person just tells others that a change is
coming at such-and-such time, and to react accordingly.
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.
Yeah, that had me scratching my head as well. I might want to be notified
that the change could be applied in more places, but such a heuristic is too
complex to make automatic.
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.
As someone who has used git for contributing to a few projects now, there is
a bit more to it. While private branches can be considered bad for
structured environments, they are incredibly good for open source
environments. I recently had a bug in a local branch which I spent a long
time fixing, including breaking individual commits out into smaller pieces
to find out when certain regressions (turned out to be two) occurred.
I might have not wanted all of that sort of experimentation to appear in a
public repository. Which means, I wouldn't have used the tool available to
help me solve the problem. In that particular case, disconnected operation
really helped me.
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.
Branches can point to a remote location for push/pull ops, such a branch is
said to be 'tracking'. You can track many different branches, with
commonalities being reduced to the same objects in the object database.
-David Waite
Received on Fri Nov 2 17:13:19 2007