Re: FFmpeg considering GIT

From: david@lang.hm <david@lang.hm>
Date: May 3, 2007, 20:05 UTC
Message-ID: <Pine.LNX.4.64.0705031302110.26172@asgard.lang.hm>
In-Reply-To: <20070503200013.GG4489@pasky.or.cz>

On Thu, 3 May 2007, Petr Baudis wrote:

Show 26 quoted lines

> 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