On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:
That sounds like an opportunity to educate your contributors a bit on
what good commits should look like. So I think this is more a social
issue than a technical issue, (but git has some technical means that
make it much easier to address the social issues).
Your description above makes an assumption that there is a single
central repository that multiple people push changes into, (which is
really the only way to organize a project with svn or cvs). And with
those systems all you get is a bit than you can flip on for whether
you trust someone to push changes into the repository or not. But git
is much more flexible than that.
The opposite extreme is to organize the project in a way similar to
the linux kernel---all contributors maintain their own repositories
and things get merged only when a maintainer reviews and pulls. With
this approach, garbage never lands in your own repository by
definition, (since you don't pull if it looks like garbage to you). So
that solves the problem, but this organization might seem too radical
a shift for your project.
Fortunately, git is flexible enough to do things in between as
well. For example, you can have a central repository where multiple
people push changes, and also have personal repositories. Git reduces
the cost of creating a new personal repository to basically zero, so
you can use these quite freely. They make a great place for new
contributors to publish changes where the more experienced maintainers
can review and educate the new contributors on mistakes like you
describe above.
So with this, you can let people play in their own repositories while
they're still learning the cultural aspects of what code should look
like. I've found that new contributors really like the freedom this
gives them, (there's no fear that they are going to break anything
this way, since they are relying on others to review and pull at
first). So the trust relationship can grow as you work together,
(which is how it should be).
And that whole relationship-building happens while you're both
benefiting from the support of the tool, (not like cvs or svn where
the new contributor is cut off from almost all help from the tool
until you flip the "absolute trust" bit).
That sounds like a bad technical workaround for a problem that really
shouldn't exist. You should look for ways to create the history you'd
really like to have rather than trying to find a way to get the tool
to ignore the history that's actually there.
Sure, mistakes will happen. Just learn to live with that.
Oh, and I also think the emphasis on "blame" is due to a lack of other
more powerful history exploration features in other systems. For
example, the fact that "git log" can filter based on subsets of the
directory tree:
git log -p -- some/directory
or by content of the patches themselves:
git log -p -S'snippet of interest'
[*]
is often just plain more powerful than blame is, and it makes it quite
trivial to skip past any noise, (since you get the complete history of
what you care about, not just information about the last time a line
in a file got touched).
For example, I often use git-log to find out what happened to code
that used to be in the file, but doesn't appear there anymore. That's
simple to do with git log, (sometimes even just plain "git log -p" and
searching with the pager), but it's something that something like cvs
or svn blame just fundametally cannot even help with.
-Carl
[*] I just noticed that -S isn't mentioned in the documentation for
git-log at all, (though, oddly enough, a 'git log -S' example is
provided in the git-blame documentation).
