[FFmpeg-devel] [GIT] ready by the weekend
Wed Dec 1 22:47:26 CET 2010
On 1 December 2010 22:32, Luca Barbato <lu_zero at gentoo.org> wrote:
> On 12/1/10 10:24 PM, Rob wrote:
>> I know how to use git and I think it's easier to unwittingly screw up
>> with git and end up with no feet. ;) So, personally I think it's good
>> to have this guide be quite detailed and explicit and perhaps have a
>> warning that if people are unsure, they should ask.
>> I can quite well imagine someone screwing up a bit and making
>> something messy happen in the public repo and then someone who knows
>> how to use git exploding all over them for doing so. Or people may be
>> more tolerant of mistakes and we just fix them as we go, I dunno.
> How about
> "Always either push to your public tree or send the changes as email before
> even thinking about issuing git push" ?
Perhaps. I think it's always good practice to have your stuff reviewed
by at least one other person before it gets merged into the main repo,
even if you're a maintainer. Even if someone doesn't understand the
theory behind what you're coding, they should be able to review the
code and query things before it gets merged. Of course one can offer a
window of time for comments before merging to avoid holding up one's
development waiting for reviews, though with the suggested staging
repo or even with ones own local repos, there's no hold up.
> Or adding a staging tree so everybody can push and ask others to evaluate
> and merge to the main?
I thought this was a good idea but it needs someone to manage the
merging into main otherwise we could end up with a whole mess of
bit-rotting branches. :) It may serve to be a nice history though.
> in git you hardly screw up others (beside while using git push -f)
Right, and it seems that it is (smart) common practice for a project
repo to disallow non-fastforward commits. So there's nothing to worry
about there. I rather meant things like merge commits and poor commit
messages and such.
More information about the ffmpeg-devel