From: david@lang.hm Date: Thu, 03 May 2007 20:05:34 GMT Subject: Re: FFmpeg considering GIT Message-ID: In-Reply-To: <20070503200013.GG4489@pasky.or.cz> On Thu, 3 May 2007, Petr Baudis wrote: > On Thu, May 03, 2007 at 08:00:16PM CEST, Uwe Kleine-König wrote: > > I believe that the development scheme is largely independent on the > version control system, except that git makes the "both ways" equally > easy. But that doesn't mean that the "multiple people with commit > access" scheme is wrong or anything. It has important upsides as well - > there's no single human point of failure (_yes_, if the maintainer gets > stuck in hospital for two months you can fork and maintain own > repository, but then it's again just you and it is complicated socially > etc.), the load of the maintainer is significantly lowered, and in many > projects there is simply no "single maintainer" but a team of people > where decisions are made by consensus. > > Still, if this kind of bogus change checkins happens at any frequent > rate in the ffmpeg project, there is a serious problem somewhere. :-) > But I think the git way of alleviating this problem would be to have a > way to hint the pickaxe and blame tools to ignore changes in given > commits. So, you don't _cover up_ the messy things that happened during > the history, but avoid in getting in the way in your view. You can still > look it up (with git log or something) in case you'd need to (perhaps > the revert patch was a bit complicated because of conflicting with some > other changes, and a subtle bug was introduced; this would be thousand > times harder to track down if you would've rewritten the history). > > Would crafting up a patch to implement something like this help ffmpeg > people in their decision? is this needed? wouldn't you do something like a--b--c--d oops, b was really bad rebase c b a--b--c--d \ c'--d'--e--f and you just start tagging d', e, f as the releases, logicly changing things to a--b--c'--d'--e--f \ c--d dead branch the only thing that this costs is space. unless it's a 'mess up all the whitespace in the entire tree' type of thing (and if it was, whoever did the commit would see the _huge_ diffstat and probably catch it) it's not likely to be a significant amount of space in the overall history. David Lang