Hello again, Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this. Regards, -- Clément B. Not sent from a jesusPhone.
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer.
Though no developer, I endorse this. Git is awesome. Ingo
On 21 dec 2010, at 11:54, Clément Bœsch <ubitux@gmail.com> wrote:
Hello again,
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
I so far assumed that both would be moved at more or less the same time, in a way that keeps the embedded FFmpeg checkout working, everything else would be quite a mess, at least for any less advanced users.
On Wed, Dec 22, 2010 at 06:01:22PM +0100, Reimar Döffinger wrote:
On 21 dec 2010, at 11:54, Clément Bœsch <ubitux@gmail.com> wrote:
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
I so far assumed that both would be moved at more or less the same time, in a way that keeps the embedded FFmpeg checkout working, everything else would be quite a mess, at least for any less advanced users.
Unfortunately your assumption is baseless, there is nobody working on migrating MPlayer. Note that I'm not saying I'm opposed, I'm just stating facts. Diego
On 2 jan 2011, at 10:37, Diego Biurrun <diego@biurrun.de> wrote:
On Wed, Dec 22, 2010 at 06:01:22PM +0100, Reimar Döffinger wrote:
On 21 dec 2010, at 11:54, Clément Bœsch <ubitux@gmail.com> wrote:
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
I so far assumed that both would be moved at more or less the same time, in a way that keeps the embedded FFmpeg checkout working, everything else would be quite a mess, at least for any less advanced users.
Unfortunately your assumption is baseless, there is nobody working on migrating MPlayer. Note that I'm not saying I'm opposed, I'm just stating facts.
While it may be wrong, it is not baseless, that was the plan that was stated during one of the initial discussions. I also assumed it to be necessary in order to be able to test that integrating the FFmpeg subtree actually works with git (most of the time I have heard only bad things about git in that regard), since there are still quite a few FFmpeg developer using MPlayer AFAICT knowing whether we will risk losing that tight integration forever with the git switch would be useful information...
On Sun, Jan 02, 2011 at 12:51:51PM +0100, Reimar Döffinger wrote:
On 2 jan 2011, at 10:37, Diego Biurrun <diego@biurrun.de> wrote:
On Wed, Dec 22, 2010 at 06:01:22PM +0100, Reimar Döffinger wrote:
On 21 dec 2010, at 11:54, Clément Bœsch <ubitux@gmail.com> wrote:
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
I so far assumed that both would be moved at more or less the same time, in a way that keeps the embedded FFmpeg checkout working, everything else would be quite a mess, at least for any less advanced users.
Unfortunately your assumption is baseless, there is nobody working on migrating MPlayer. Note that I'm not saying I'm opposed, I'm just stating facts.
While it may be wrong, it is not baseless, that was the plan that was stated during one of the initial discussions.
Scratch that wording of mine, sounds harsher than I meant it to sound.
I also assumed it to be necessary in order to be able to test that integrating the FFmpeg subtree actually works with git (most of the time I have heard only bad things about git in that regard), since there are still quite a few FFmpeg developer using MPlayer AFAICT knowing whether we will risk losing that tight integration forever with the git switch would be useful information...
It seems like it's time for me to respin my patchset that decouples FFmpeg from MPlayer... Diego
Reimar Döffinger wrote on Sun, 2 Jan 2011 12:51:51 +0100:
I also assumed it to be necessary in order to be able to test that integrating the FFmpeg subtree actually works with git
Though I never used it before, 'git submodule' should do the job, but I seem to learn from this thread that I shouldn't wait for git, should I? Ingo
On Sun, Jan 02, 2011 at 04:12:17PM +0100, Ingo Brückl wrote:
Reimar Döffinger wrote on Sun, 2 Jan 2011 12:51:51 +0100:
I also assumed it to be necessary in order to be able to test that integrating the FFmpeg subtree actually works with git
Though I never used it before, 'git submodule' should do the job, but I seem to learn from this thread that I shouldn't wait for git, should I?
Waiting for git would be an unwise thing to do indeed. Diego
Clément wrote on Tue, 21 Dec 2010 11:54:53 +0100:
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer.
Is there a target date? Ingo
On 12/21/2010 11:54 AM, Clément Bœsch wrote:
Hello again,
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
Regards,
Here what's missing to get mplayer move to git (ffmpeg is almost done) 1)- Documentation: I wrote an howto for ffmpeg, could be shared. 2)- Map commits to users: might be possible to recycle janne script 3)- Amend history: do we really want to do that? 4)- gather ssh keys and install gitolite or gitosis on natsuki 5)- Switch to use git for the ffmpeg-mplayer import 6)- Update tree 2 and 3 could be replaced by a simple import using git-svn and be done with that. That assuming there is consensus on moving to git. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
On Sun, Jan 09, 2011 at 12:48:44PM +0100, Luca Barbato wrote:
On 12/21/2010 11:54 AM, Clément Bœsch wrote:
Hello again,
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
Regards,
Here what's missing to get mplayer move to git (ffmpeg is almost done)
1)- Documentation: I wrote an howto for ffmpeg, could be shared. 2)- Map commits to users: might be possible to recycle janne script
Personal entry: cboesch = Clément Bœsch <ubitux gmail>
3)- Amend history: do we really want to do that? 4)- gather ssh keys and install gitolite or gitosis on natsuki
Attached mine. Btw, gitosis seems not maintained anymore, so I'd say gitolite is more appropriate.
5)- Switch to use git for the ffmpeg-mplayer import 6)- Update tree
2 and 3 could be replaced by a simple import using git-svn and be done with that.
That assuming there is consensus on moving to git.
What more can I do? -- Clément B.
On 01/09/2011 01:32 PM, Clément Bœsch wrote:
On Sun, Jan 09, 2011 at 12:48:44PM +0100, Luca Barbato wrote:
On 12/21/2010 11:54 AM, Clément Bœsch wrote:
Hello again,
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
Regards,
Here what's missing to get mplayer move to git (ffmpeg is almost done)
1)- Documentation: I wrote an howto for ffmpeg, could be shared. 2)- Map commits to users: might be possible to recycle janne script
Personal entry: cboesch = Clément Bœsch <ubitux gmail>
3)- Amend history: do we really want to do that? 4)- gather ssh keys and install gitolite or gitosis on natsuki
Attached mine. Btw, gitosis seems not maintained anymore, so I'd say gitolite is more appropriate.
I already hacked on gitosis, I might check what to do with gitolite or work with mru in having a smaller and simpler access script since he had some ideas about it, still the person deciding on that should be Attila.
5)- Switch to use git for the ffmpeg-mplayer import 6)- Update tree
2 and 3 could be replaced by a simple import using git-svn and be done with that.
That assuming there is consensus on moving to git.
What more can I do?
Pick janne scripts and try to see what happens when they run on the mplayer svn ^^; lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
On Sun, 09 Jan 2011 12:48:44 +0100, Luca Barbato wrote:
4)- gather ssh keys and install gitolite or gitosis on natsuki
there is this: http://git.mplayerhq.hu/ but i am not sure how its setup at all. -compn
On 9 Jan 2011, at 12:48, Luca Barbato <lu_zero@gentoo.org> wrote:
That assuming there is consensus on moving to git.
I do think there is consensus we want to switch with FFmpeg or ASAP after, IMO it is of advantage to both projects (admittedly more for MPlayer) to be tightly coupled.
On 01/09/2011 08:49 PM, Reimar Döffinger wrote:
On 9 Jan 2011, at 12:48, Luca Barbato <lu_zero@gentoo.org> wrote:
That assuming there is consensus on moving to git.
I do think there is consensus we want to switch with FFmpeg or ASAP after, IMO it is of advantage to both projects (admittedly more for MPlayer) to be tightly coupled.
One of the open questions is how to manage access to the share repository, we are always using ssh but we can have: - a shared restricted user (per project?) - access through gitosis - access through gitolite the difference is mostly on the granularity of the acl we can use (none, per repo, per path). switching from one to another is relatively easy so we could go with the first and move to the complex ones if the need arises. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Luca Barbato ha scritto:
One of the open questions is how to manage access to the share repository, we are always using ssh but we can have:
- a shared restricted user (per project?) - access through gitosis - access through gitolite
the difference is mostly on the granularity of the acl we can use (none, per repo, per path).
switching from one to another is relatively easy so we could go with the first and move to the complex ones if the need arises.
lu
what's the advantage of git over svn? I don't know if and when I'll have the time to return coding for mplayer, but in case I'd like to know what death to die for:) . You know, I'm quite conservative regarding my development tools.
On 1/12/11 5:02 PM, Nico Sabbi wrote:
what's the advantage of git over svn? I don't know if and when I'll have the time to return coding for mplayer, but in case I'd like to know what death to die for:) . You know, I'm quite conservative regarding my development tools.
Faster Compact (the whole history takes the space of a single svn checkout...) Better tools provided by default (git grep, git bisect, git checkout -p) Easier way to send and merge patches (git send-email, git format-patch, git am) Better tracking of files (git tracks lines and discovers rewrites and renames by itself) And probably some other stuff I'm forgetting I wrote for ffmpeg a small guide, it gives most of the pointers for get an idea of the commands (they are a bit different). lu
On Wed, Jan 12, 2011 at 09:46:29PM +0100, Luca Barbato wrote:
On 1/12/11 5:02 PM, Nico Sabbi wrote:
what's the advantage of git over svn? I don't know if and when I'll have the time to return coding for mplayer, but in case I'd like to know what death to die for:) . You know, I'm quite conservative regarding my development tools.
Faster
Compact (the whole history takes the space of a single svn checkout...)
Better tools provided by default (git grep, git bisect, git checkout -p)
Easier way to send and merge patches (git send-email, git format-patch, git am)
Better tracking of files (git tracks lines and discovers rewrites and renames by itself)
And probably some other stuff I'm forgetting
The main argument is that being decentralized it offers the ability to be totally free with the history; so stacking and reorganize patches for example is much more easier. And of course it's not the only benefit from being decentralized… If you need a bit more propaganda: http://www.youtube.com/watch?v=4XpnKHJAok8 -- Clément B.
Hi, On Wed, Jan 12, 2011 at 09:46:29PM +0100, Luca Barbato wrote:
On 1/12/11 5:02 PM, Nico Sabbi wrote:
what's the advantage of git over svn? I don't know if and when I'll have the time to return coding for mplayer, but in case I'd like to know what death to die for:) . You know, I'm quite conservative regarding my development tools.
Faster
Compact (the whole history takes the space of a single svn checkout...)
Better tools provided by default (git grep, git bisect, git checkout -p)
Easier way to send and merge patches (git send-email, git format-patch, git am)
Especially when working on a bigger feature it's nice to make several local commits and then send a patch series instead of one huge patch.
Better tracking of files (git tracks lines and discovers rewrites and renames by itself)
And probably some other stuff I'm forgetting
I really like git stash: you work on something, stumble upon an existing bug, git stash your current work, fix the bug, commit this fix, and continue working on your feature after reapplying the stashed changes.
I wrote for ffmpeg a small guide, it gives most of the pointers for get an idea of the commands (they are a bit different).
The "git cheat cheat" at http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html is quite nice as a quick reminder. Erik -- Rule 34: If you’re leaving scorch-marks, you need a bigger gun. -- The Seven Habits of Highly Effective Pirates
Luca Barbato <lu_zero@gentoo.org> wrote:
On 1/12/11 5:02 PM, Nico Sabbi wrote:
what's the advantage of git over svn? I don't know if and when I'll have the time to return coding for mplayer, but in case I'd like to know what death to die for:) . You know, I'm quite conservative regarding my development tools.
[...]
And probably some other stuff I'm forgetting [...]
The local checkout is complete. Browsing the history, commiting, merging, etc. can be done offline. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
2011/1/12 Nico Sabbi <nicola.sabbi@poste.it>:
what's the advantage of git over svn? I don't know if and when I'll have the time to return coding for mplayer, but in case I'd like to know what death to die for:) . You know, I'm quite conservative regarding my development tools.
i'm an outsider here, and i don't know actually know much about svn, but my 2 cents :P for me the selling point of git is cheap branching. you can make a new branch just for a single feature, and when you are done you don't even need to keep it, you can just rebase your work to have a linear history, and throw away the branch. (it makes it appear as you never branched, and you can also choose to rebase into a later commit if history advanced) by separating each feature in a branch and doing small commits all the time one can try another approaches easily, and work with features/bugfixes concurrently without making history too ugly, like interleaving unrelated commits (or getting yourself mad). and, i think it makes easier to undo work. and all of this is very fast (thanks to local repo) also, git has very, very good merging tools. and it is easy. i think that without this, branching all the time would be a nightmare :P and, git lets one have finer grained control about which content will be at every commit, you can even select which lines of the file you changed will be in the next commit (in case that you did two bug fixes, and want each one to have their same commit; you do git add --edit, then select the exact diff that will be added in the next commit). and if you get something wrong (a typo or something) and it is still just at your local machine only, history doesn't need to get uglier: you can fix commits easily (changing the last commit you issued is specially easy, just git commit --amend) anyway there are tons of sites about this. i liked this http://whygitisbetterthanx.com/#svn , and i will also point to http://stackoverflow.com/questions/871/why-is-git-better-than-subversion/531... and hmm i know you could google yourself, but, http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/ it can help one understand why git branches are a win (svn has branches, but they aren't as easy, so they get less used)
On Tue, Dec 21, 2010 at 11:54:53AM +0100, Clément Bœsch wrote:
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
I think git is the way to go in the long run, but I see no rush in making the switch in the short run. A reasonable compromise would be to start using git-svn first in order to get used to working with git. I'll start a new thread about it. Diego
On Sat, Jan 22, 2011 at 07:59:40PM +0100, Diego Biurrun wrote:
On Tue, Dec 21, 2010 at 11:54:53AM +0100, Clément Bœsch wrote:
Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this.
I think git is the way to go in the long run, but I see no rush in making the switch in the short run. A reasonable compromise would be to start using git-svn first in order to get used to working with git. I'll start a new thread about it.
If I'm not wrong, the external FFmpeg repository is stalled until we move to git, no? Also, given the number of current active developers, maybe we should take the opportunity to do the migration? -- Clément B.
participants (11)
-
Andreas Metzler -
Clément Bœsch -
compn -
Diego Biurrun -
Elias Gabriel Amaral da Silva -
Erik Auerswald -
Ingo Brueckl -
Ingo Brückl
-
Luca Barbato -
Nico Sabbi -
Reimar Döffinger