[PATCH] proper version info for git.mplayerhq.hu
I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info. The format will be: git-<commithash>-<gccversion> if mplayer is built from "master", and git-<closest commithash on master>-<commithash>-<gccversion> if mplayer is built from another branch. In my case, at the moment it prints: MPlayer git-15dfe0a-ceba2bd-4.4.1 (C) 2000-2010 MPlayer Team It changes nothing if run from a svn repository. Best regards, Rudolf Polzer
Rudolf Polzer <divVerent <at> alientrap.org> writes:
I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info.
Wouldn't it be better to show the svn version from which the git repository was cloned? (I believe this is how FFmpeg does it.) Carl Eugen
On Mon, Jul 26, 2010 at 09:05:31AM +0000, Carl Eugen Hoyos wrote:
Rudolf Polzer <divVerent <at> alientrap.org> writes:
I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info.
Wouldn't it be better to show the svn version from which the git repository was cloned? (I believe this is how FFmpeg does it.)
Only as long as the git stays read-only. Just because no such move is planned YET, it does not mean it won't happen in some years. I attached a more elaborate version. It now shows, "in order of likelihood": SVN-r12345-4.4.1 if it is identical to a git-svn commit in master SVN-r12345+LOCAL-4.4.1 if it is identical to a git-svn commit in master plus local uncommitted changes SVN-r12345+badf00d-4.4.1 if it is identical to a git commit not on master that is derived from a git-svn commit on master SVN-r12345+badf00d+LOCAL-4.4.1 if it is identical to a git commit not on master that is derived from a git-svn commit on master plus local uncommitted changes git-dedbeef-4.4.1 if it is identical to a git commit on master git-dedbeef+LOCAL-4.4.1 if it is identical to a git commit on master plus local changes git-dedbeef+badf00d-4.4.1 if it is identical to a git commit not on master that is derived from a git commit on master git-dedbeef+badf00d+LOCAL-4.4.1 if it is identical to a git commit not on master that is derived from a git commit on master git+badf00d-4.4.1 if it is identical to a git commit not on master that has no common history with master git+badf00d+LOCAL-4.4.1 if it is identical to a git commit not on master that has no common history with master plus local changes Is that beter? Best regards, Rudolf Polzer
On 26/07/2010, at 7:40 PM, Rudolf Polzer wrote:
On Mon, Jul 26, 2010 at 09:05:31AM +0000, Carl Eugen Hoyos wrote:
Rudolf Polzer <divVerent <at> alientrap.org> writes:
I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info.
Wouldn't it be better to show the svn version from which the git repository was cloned? (I believe this is how FFmpeg does it.)
Only as long as the git stays read-only. Just because no such move is planned YET, it does not mean it won't happen in some years.
I attached a more elaborate version. It now shows, "in order of likelihood": <...>
Where there is an ID for a commit in 'master' included, do you mean 'origin/master'? The building user's 'master' branch could potentially include any number of local commits never to be pushed - in fact, it's the default HEAD for such commits to be added to; and you really don't want to squelch the origin commit it was based on. I know I do all sorts of weird and wonderful things with my local master for my 'day job' between pushes. I like the showing of SVN revision where it's available; but once there are git commits involved, you want to make sure you indicate which (origin/master) commit is most recent in the current branch, and as you mention, _if_ there are any others. So, to fit my pattern-substitution oriented thought process: (official)(+local tracked)(+LOCAL)-4.4.1 Where: 'official' would be either the SVN r.#, or the origin/master commit ID 'local tracked' would be the latest git commit ID on the current branch, if different from 'official' - nothing for SVN-sourced working copies. '+LOCAL' indicates untracked changes, as before Even this doesn't sit well with users cloning from each other (interesting mental image...); as origin/master will point to whatever remote branch they started with. The effect of that should be limited though, the ID will just not be any commit in the official repo... -- I know I'm new to the list (Greetings! btw), and I especially don't want to give the impression that I don't support this change, or that I'm here to nitpick. I've just been bitten hard by ambiguous versioning in bug reports.
On Mon, Jul 26, 2010 at 10:45:55PM +1000, Rowan James wrote:
On 26/07/2010, at 7:40 PM, Rudolf Polzer wrote:
On Mon, Jul 26, 2010 at 09:05:31AM +0000, Carl Eugen Hoyos wrote:
Rudolf Polzer <divVerent <at> alientrap.org> writes:
I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info.
Wouldn't it be better to show the svn version from which the git repository was cloned? (I believe this is how FFmpeg does it.)
Only as long as the git stays read-only. Just because no such move is planned YET, it does not mean it won't happen in some years.
I attached a more elaborate version. It now shows, "in order of likelihood": <...>
Where there is an ID for a commit in 'master' included, do you mean 'origin/master'?
Yes, see patch.
The building user's 'master' branch could potentially include any number of local commits never to be pushed - in fact, it's the default HEAD for such commits to be added to; and you really don't want to squelch the origin commit it was based on. I know I do all sorts of weird and wonderful things with my local master for my 'day job' between pushes.
Exactly.
I like the showing of SVN revision where it's available; but once there are git commits involved, you want to make sure you indicate which (origin/master) commit is most recent in the current branch, and as you mention, _if_ there are any others.
So, to fit my pattern-substitution oriented thought process:
(official)(+local tracked)(+LOCAL)-4.4.1
Where: 'official' would be either the SVN r.#, or the origin/master commit ID 'local tracked' would be the latest git commit ID on the current branch, if different from 'official' - nothing for SVN-sourced working copies. '+LOCAL' indicates untracked changes, as before
That is what it does, yes.
Even this doesn't sit well with users cloning from each other (interesting mental image...); as origin/master will point to whatever remote branch they started with. The effect of that should be limited though, the ID will just not be any commit in the official repo...
But as long as the official repo is git-svn based, it will be an obvious difference.
On 27/07/2010, at 2:58 PM, Rudolf Polzer wrote:
On Mon, Jul 26, 2010 at 10:45:55PM +1000, Rowan James wrote:
Where there is an ID for a commit in 'master' included, do you mean 'origin/master'?
Yes, see patch.
Even this doesn't sit well with users cloning from each other (interesting mental image...); as origin/master will point to whatever remote branch they started with. The effect of that should be limited though, the ID will just not be any commit in the official repo...
But as long as the official repo is git-svn based, it will be an obvious difference.
Yep, as long as that holds; and even if it doesn't, IDs are effectively globally unique anyway. Looks good to me =)
On Tue, Jul 27, 2010 at 04:54:35PM +1000, Rowan James wrote:
On 27/07/2010, at 2:58 PM, Rudolf Polzer wrote:
On Mon, Jul 26, 2010 at 10:45:55PM +1000, Rowan James wrote:
Where there is an ID for a commit in 'master' included, do you mean 'origin/master'?
Yes, see patch.
Even this doesn't sit well with users cloning from each other (interesting mental image...); as origin/master will point to whatever remote branch they started with. The effect of that should be limited though, the ID will just not be any commit in the official repo...
But as long as the official repo is git-svn based, it will be an obvious difference.
Yep, as long as that holds; and even if it doesn't, IDs are effectively globally unique anyway.
Looks good to me =)
As I got no further reply to this, and would really like to see this applied, I attached the current version of this again and ask: is anything important missing? Can this get applied? It: - clearly changes nothing for svn users - if a user of our official git repo has an unmodified repo, he will see the same version number as if he has used svn - if he has changes to svn, he gets SVN-r12345+3eb79c1 to also contain his git hash - if the SVN revision cannot be identified (e.g. because he pulled from another repo, e.g. uau's in case uau merges this change), you just git git-3eb79c1 (possibly appended with +1f9a317 for local changes) I get, for example: MPlayer SVN-r32671+12b7526-4.5.1 (C) 2000-2010 MPlayer Team Best regards, Rudolf Polzer
On Sat, Dec 04, 2010 at 10:41:55AM +0100, Rudolf Polzer wrote:
On Tue, Jul 27, 2010 at 04:54:35PM +1000, Rowan James wrote:
On 27/07/2010, at 2:58 PM, Rudolf Polzer wrote:
On Mon, Jul 26, 2010 at 10:45:55PM +1000, Rowan James wrote:
Where there is an ID for a commit in 'master' included, do you mean 'origin/master'?
Yes, see patch.
Even this doesn't sit well with users cloning from each other (interesting mental image...); as origin/master will point to whatever remote branch they started with. The effect of that should be limited though, the ID will just not be any commit in the official repo...
But as long as the official repo is git-svn based, it will be an obvious difference.
Yep, as long as that holds; and even if it doesn't, IDs are effectively globally unique anyway.
Looks good to me =)
As I got no further reply to this, and would really like to see this applied, I attached the current version of this again and ask: is anything important missing? Can this get applied?
It: - clearly changes nothing for svn users - if a user of our official git repo has an unmodified repo, he will see the same version number as if he has used svn
And "LOCAL".
- if he has changes to svn, he gets SVN-r12345+3eb79c1 to also contain his git hash - if the SVN revision cannot be identified (e.g. because he pulled from another repo, e.g. uau's in case uau merges this change), you just git git-3eb79c1 (possibly appended with +1f9a317 for local changes)
I get, for example: MPlayer SVN-r32671+12b7526-4.5.1 (C) 2000-2010 MPlayer Team
Best regards,
Btw, since your working on "helpers", having a .gitignore and an update script in TOOLS with sth like "(cd ffmpeg; git pull); (cd ffmpeg/libswscale; git pull); (cd libdvdnav/; svn up); (cd libdvdread4/; svn up)" could be nice... And maybe an init script too :-) But well, that's not what your patch is about. Regarding the patch, what happen if git is not installed on the user system? -- Clément B. Not sent from a jesusPhone.
On Sat, Dec 04, 2010 at 11:41:09AM +0100, Clément Bœsch wrote:
On Sat, Dec 04, 2010 at 10:41:55AM +0100, Rudolf Polzer wrote:
As I got no further reply to this, and would really like to see this applied, I attached the current version of this again and ask: is anything important missing? Can this get applied?
It: - clearly changes nothing for svn users - if a user of our official git repo has an unmodified repo, he will see the same version number as if he has used svn
And "LOCAL".
If the changes are also not committed, yes.
- if he has changes to svn, he gets SVN-r12345+3eb79c1 to also contain his git hash - if the SVN revision cannot be identified (e.g. because he pulled from another repo, e.g. uau's in case uau merges this change), you just git git-3eb79c1 (possibly appended with +1f9a317 for local changes)
I get, for example: MPlayer SVN-r32671+12b7526-4.5.1 (C) 2000-2010 MPlayer Team
Best regards,
Btw, since your working on "helpers", having a .gitignore and an update script in TOOLS with sth like "(cd ffmpeg; git pull); (cd ffmpeg/libswscale; git pull); (cd libdvdnav/; svn up); (cd libdvdread4/; svn up)" could be nice... And maybe an init script too :-)
But well, that's not what your patch is about.
Regarding the patch, what happen if git is not installed on the user system?
This code never gets called unless this is a git checkout. So this shouldn't be a problem. It only runs if finding the svn revision failed using svn means. Best regards, Rudolf Polzer
On Sat, Dec 04, 2010 at 03:51:29PM +0100, Rudolf Polzer wrote:
On Sat, Dec 04, 2010 at 11:41:09AM +0100, Clément Bœsch wrote:
On Sat, Dec 04, 2010 at 10:41:55AM +0100, Rudolf Polzer wrote:
As I got no further reply to this, and would really like to see this applied, I attached the current version of this again and ask: is anything important missing? Can this get applied?
It: - clearly changes nothing for svn users - if a user of our official git repo has an unmodified repo, he will see the same version number as if he has used svn
And "LOCAL".
If the changes are also not committed, yes.
- if he has changes to svn, he gets SVN-r12345+3eb79c1 to also contain his git hash - if the SVN revision cannot be identified (e.g. because he pulled from another repo, e.g. uau's in case uau merges this change), you just git git-3eb79c1 (possibly appended with +1f9a317 for local changes)
I get, for example: MPlayer SVN-r32671+12b7526-4.5.1 (C) 2000-2010 MPlayer Team
Best regards,
Btw, since your working on "helpers", having a .gitignore and an update script in TOOLS with sth like "(cd ffmpeg; git pull); (cd ffmpeg/libswscale; git pull); (cd libdvdnav/; svn up); (cd libdvdread4/; svn up)" could be nice... And maybe an init script too :-)
But well, that's not what your patch is about.
Regarding the patch, what happen if git is not installed on the user system?
This code never gets called unless this is a git checkout. So this shouldn't be a problem. It only runs if finding the svn revision failed using svn means.
If you don't have the .svn directory (some kind of snapshot done with a svn export for example), and then don't have git, it will print garbage. Just do what you said on IRC about redirecting to /dev/null, just like it's done at the moment for every svn revision wrappers. -- Clément B. Not sent from a jesusPhone.
On Wed, Dec 08, 2010 at 03:19:33PM +0100, Clément Bœsch wrote:
On Sat, Dec 04, 2010 at 03:51:29PM +0100, Rudolf Polzer wrote:
On Sat, Dec 04, 2010 at 11:41:09AM +0100, Clément Bœsch wrote:
On Sat, Dec 04, 2010 at 10:41:55AM +0100, Rudolf Polzer wrote:
As I got no further reply to this, and would really like to see this applied, I attached the current version of this again and ask: is anything important missing? Can this get applied?
It: - clearly changes nothing for svn users - if a user of our official git repo has an unmodified repo, he will see the same version number as if he has used svn
And "LOCAL".
If the changes are also not committed, yes.
- if he has changes to svn, he gets SVN-r12345+3eb79c1 to also contain his git hash - if the SVN revision cannot be identified (e.g. because he pulled from another repo, e.g. uau's in case uau merges this change), you just git git-3eb79c1 (possibly appended with +1f9a317 for local changes)
I get, for example: MPlayer SVN-r32671+12b7526-4.5.1 (C) 2000-2010 MPlayer Team
Best regards,
Btw, since your working on "helpers", having a .gitignore and an update script in TOOLS with sth like "(cd ffmpeg; git pull); (cd ffmpeg/libswscale; git pull); (cd libdvdnav/; svn up); (cd libdvdread4/; svn up)" could be nice... And maybe an init script too :-)
But well, that's not what your patch is about.
Regarding the patch, what happen if git is not installed on the user system?
This code never gets called unless this is a git checkout. So this shouldn't be a problem. It only runs if finding the svn revision failed using svn means.
If you don't have the .svn directory (some kind of snapshot done with a svn export for example), and then don't have git, it will print garbage. Just do what you said on IRC about redirecting to /dev/null, just like it's done at the moment for every svn revision wrappers.
Then the attached one should be better. Best regards, Rudolf Polzer
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
On Wed, Dec 08, 2010 at 03:19:33PM +0100, Clément Bœsch wrote:
On Sat, Dec 04, 2010 at 03:51:29PM +0100, Rudolf Polzer wrote:
On Sat, Dec 04, 2010 at 11:41:09AM +0100, Clément Bœsch wrote:
On Sat, Dec 04, 2010 at 10:41:55AM +0100, Rudolf Polzer wrote:
As I got no further reply to this, and would really like to see this applied, I attached the current version of this again and ask: is anything important missing? Can this get applied?
It: - clearly changes nothing for svn users - if a user of our official git repo has an unmodified repo, he will see the same version number as if he has used svn
And "LOCAL".
If the changes are also not committed, yes.
- if he has changes to svn, he gets SVN-r12345+3eb79c1 to also contain his git hash - if the SVN revision cannot be identified (e.g. because he pulled from another repo, e.g. uau's in case uau merges this change), you just git git-3eb79c1 (possibly appended with +1f9a317 for local changes)
I get, for example: MPlayer SVN-r32671+12b7526-4.5.1 (C) 2000-2010 MPlayer Team
Best regards,
Btw, since your working on "helpers", having a .gitignore and an update script in TOOLS with sth like "(cd ffmpeg; git pull); (cd ffmpeg/libswscale; git pull); (cd libdvdnav/; svn up); (cd libdvdread4/; svn up)" could be nice... And maybe an init script too :-)
But well, that's not what your patch is about.
Regarding the patch, what happen if git is not installed on the user system?
This code never gets called unless this is a git checkout. So this shouldn't be a problem. It only runs if finding the svn revision failed using svn means.
If you don't have the .svn directory (some kind of snapshot done with a svn export for example), and then don't have git, it will print garbage. Just do what you said on IRC about redirecting to /dev/null, just like it's done at the moment for every svn revision wrappers.
Then the attached one should be better.
It looks ok to me after a few tests and I'm ok to commit this but I need an approval of a (the?) maintainer. -- Clément B. Not sent from a jesusPhone.
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
Then the attached one should be better.
Use 4 spaces for indentation, put a space after '>' and replace `` with $(). I need to have a closer look later, but I do wonder why this is so much code... Diego
On Wed, Dec 15, 2010 at 03:14:43PM +0100, Diego Biurrun wrote:
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
Then the attached one should be better.
Use 4 spaces for indentation, put a space after '>' and replace `` with $().
Why $() is prefered over ``? Just to be consistent with the rest of the script?
I need to have a closer look later, but I do wonder why this is so much code...
I agree that could be simplified with a simple git describe just like it seems to be with FFmpeg.
Diego
-- Clément B. Not sent from a jesusPhone.
On Wed, Dec 15, 2010 at 03:18:29PM +0100, Clément Bœsch wrote:
On Wed, Dec 15, 2010 at 03:14:43PM +0100, Diego Biurrun wrote:
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
Then the attached one should be better.
Use 4 spaces for indentation, put a space after '>' and replace `` with $().
Why $() is prefered over ``?
$() is no less portable in practice and saner to nest.
Just to be consistent with the rest of the script?
That's another reason.
I need to have a closer look later, but I do wonder why this is so much code...
I agree that could be simplified with a simple git describe just like it seems to be with FFmpeg.
That's why I was wondering. I hadn't looked at FFmpeg's implementation again, but I faintly remember it being much simpler. Diego
On Wed, Dec 15, 2010 at 04:51:50PM +0100, Diego Biurrun wrote:
On Wed, Dec 15, 2010 at 03:18:29PM +0100, Clément Bœsch wrote:
On Wed, Dec 15, 2010 at 03:14:43PM +0100, Diego Biurrun wrote:
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
Then the attached one should be better.
Use 4 spaces for indentation, put a space after '>' and replace `` with $().
Why $() is prefered over ``?
$() is no less portable in practice and saner to nest.
I do remember once having used a system where `` worked and $() did not. But I doubt these systems run mplayer anyway.
I need to have a closer look later, but I do wonder why this is so much code...
I agree that could be simplified with a simple git describe just like it seems to be with FFmpeg.
That's why I was wondering. I hadn't looked at FFmpeg's implementation again, but I faintly remember it being much simpler.
git describe won't tell the svn revision the git repo bases it on. "Initialtag + revision count" doesn't necessarily match up with the svn revision. To use git describe, we should also regularily make "version tags" and such. Best regards, Rudolf Polzer
On Wed, Dec 15, 2010 at 07:44:29PM +0100, Rudolf Polzer wrote:
On Wed, Dec 15, 2010 at 04:51:50PM +0100, Diego Biurrun wrote:
On Wed, Dec 15, 2010 at 03:18:29PM +0100, Clément Bœsch wrote:
On Wed, Dec 15, 2010 at 03:14:43PM +0100, Diego Biurrun wrote:
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
Then the attached one should be better.
Use 4 spaces for indentation, put a space after '>' and replace `` with $().
Why $() is prefered over ``?
$() is no less portable in practice and saner to nest.
I do remember once having used a system where `` worked and $() did not. But I doubt these systems run mplayer anyway.
Probably some old Solaris crap default userland, but such a system won't even run MPlayer's configure... Diego
On Thu, Dec 16, 2010 at 01:33:05PM +0100, Diego Biurrun wrote:
On Wed, Dec 15, 2010 at 07:44:29PM +0100, Rudolf Polzer wrote:
On Wed, Dec 15, 2010 at 04:51:50PM +0100, Diego Biurrun wrote:
On Wed, Dec 15, 2010 at 03:18:29PM +0100, Clément Bœsch wrote:
On Wed, Dec 15, 2010 at 03:14:43PM +0100, Diego Biurrun wrote:
On Thu, Dec 09, 2010 at 07:30:59AM +0100, Rudolf Polzer wrote:
Then the attached one should be better.
Use 4 spaces for indentation, put a space after '>' and replace `` with $().
Why $() is prefered over ``?
$() is no less portable in practice and saner to nest.
I do remember once having used a system where `` worked and $() did not. But I doubt these systems run mplayer anyway.
Probably some old Solaris crap default userland, but such a system won't even run MPlayer's configure...
Fine, attached.
participants (5)
-
Carl Eugen Hoyos -
Clément Bœsch -
Diego Biurrun -
Rowan James -
Rudolf Polzer