At 1:27 AM -0400 11/1/07, Greg Hudson 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.
I haven't seen this video yet, but I did sit on another presentation
on GIT which was about two orders of magnitude more useful than the
rant^H^H^H^Htalk that Linus gave at Google.
One key thing about GIT is that you want to commit early, and commit
often. This works quite well with GIT, because you are NOT committing
to any official repository. You're just telling GIT "remember these
four lines as a single change". Or "remember that this file appeared
and that file disappeared as a single change".
You don't have a temporarily broken build, unless you're crazy
enough to build it yourself (from your own local repository) when
you know damn well that it won't compile. You're never breaking
any build in any other repository, because YOU CAN'T TOUCH ANY
OTHER REPOSITORY. Other repositories *pull* specific revisions from
your repository -- and they only do that once you tell them which
revision is safe for them to pull from you. Yes, you could tell
them to pull a revision which you know will break their build, but
you would only do that a few times before they would blacklist your
That is a significant change in mindset for those of us who are used
to committing changes into TheOneTrueRepository(TM) for our projects.
To us, a commit is a scary thing that BETTER NOT BREAK THE BUILD!
But once you get past that new mindset, I suspect it's pretty easy to
have project management work fairly well in GIT. We're used to
"commit when you have it working right". GIT assumes "commit early
and commit often -- even when it isn't working".
I'm not sure I would want to switch completely to way GIT works, but I
can see some of the benefits from it. I suspect there's a number of
good ideas which could be transplanted from GIT to svn.
I have CVS/svn usage so ingrained that I'm not completely comfortable
with making commits of code that I know will not work. But maybe we
could have some idea of "subcommits".
Garance Alistair Drosehn = firstname.lastname@example.org
Senior Systems Programmer or email@example.com
Rensselaer Polytechnic Institute or firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Nov 2 05:25:40 2007