On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote: > well, my example above was exagerated, noone ever reindented the whole > ffmpeg or checked in a old version over HEAD. what did and does occasionally > happen is that people check in several things at once (like a 100k reindenton > mixed with various functional changes) 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). > well if git blame and others could somehow be told to automatically ignore > nonsense changes and matching nonsense reverts that would be great > maybe by searching for some keyword in the revert message? 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).
Attachment:
pgp0quVuQ5kLh.pgp
Description: PGP signature