Re: FFmpeg considering GIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]