At 1:05 AM -0700 11/2/07, Karl Fogel wrote:
>Garance A Drosihn <drosih@rpi.edu> writes:
> > One key thing about GIT is that you want to commit early, and
> > commit often.
> > 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!
>
>Note that this is how we're working in the Subversion repository right
>now. You make a branch, do your work there, and then push ("pull",
>whatever) the changes to trunk when they're ready. The developer who
>made the change could do that merge, or someone else could, it doesn't
>matter. The point is that this method works fine with Subversion.
>Commits are certainly not inherently "scary things".
>
>So this mindset is not new, and not unique to GIT.
Well, I didn't meant to say it is a new idea for all subversion users
or that it is a change which requires GIT. But for *some* developers
in *some* projects this is a pretty major paradigm shift (woo). And for
those developers, I think it is useful to wave a flag around explicitly
pointing out this difference in philosophy, or they will keep thinking
about commits the same way they have always thought about them.
I also found this was a significant point which was not presented at
all well by Linus. Some features are presented as if they are magical
capabilities of GIT, and yet (IMO) those features are not really tied
to GIT, and they are not magical. They are possible due to "commit
early and commit often". And while GIT promotes that behavior, it
seems to me that GIT is not required to support it. And conversely,
if developers switch to GIT but do *not* change their own behavior,
then they won't learn much from their experience with GIT. It'll just
be CVS with different commands.
I (for one) certainly had trouble understanding how GIT could do many
of the things that Linus bragged about, until I realized just how
important this "commit early and commit often" behavior was to almost
everything he talked about. If someone creates their on branch in
GIT, and then works on it for three months before they try to merge
all that work back into the main branch, then they are going to have
just as much trouble with GIT as they would have with subversion.
> > I have CVS/svn usage so ingrained that I'm not completely comfortable
>> with making commits of code that I know will not work.
>
>Huh? I have no problem making commits that I know won't work, if I
>know that I'm committing them to a branch that's not expected to work.
I'm thinking more of what happens once the work is merged into a
main branch. Let's say a tiny part of a much bigger change is to
move a subroutine from one source-file to some other source-file. I
want that move to show up as a separate commit, so that the SCM can
(all by itself) annotate that "this subroutine was the one originally
written in 1997 and moved to this file in 2007", and not mistakenly
claim "This routine was written for the first time in 2007". That is
a feature which GIT brags about, and which strikes me as very useful.
But let's say that someone comes along later, and is trying to pin
down where some obscure bug was introduced to the larger project.
*Very* often, the easiest way to do this is to do a binary search
through commit-history. "Did the bug exist in repo revision #200?
No. Revision 300? Yes. Revision 250? No." [etc]. In *that*
context, I don't want to waste the time of that developer by having
them pick some revision number which I know is not going to compile.
Note that I *do* want the commit to be there, for the best results
from annotate. But I don't want anyone to waste their time trying
to compile that specific revision. That's why I was thinking of
maybe having something like "subcommits". Some way to save a small
part of some larger change, while making it clear that that specific
commit isn't going to work well for anyone.
disclaimer: I tend to type too much, and I tend to sound like I'm
arguing when I don't mean to be. Apologies if I'm doing that here.
I'll now go and watch Randal's excellent presentation. :-)
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 3 00:33:22 2007