[x264-devel] [PATCH] Hack for svnversion equivalent on git

Pierre d'Herbemont pdherbemont at free.fr
Sun Mar 9 14:01:30 CET 2008


On Mar 9, 2008, at 6:39 AM, Jason Martens wrote:

>
> On Mar 8, 2008, at 6:50 AM, Pierre d'Herbemont wrote:
>
>> Note that you get git-746-2, which means 2 commits after 746.
>
> But that 2 will increment with each commit regardless of where it's
> made.  It tells you nothing important _about_ the commits.  Are they
> local commits?  Are they already in the HEAD at git.videolan.org?  You
> don't know; all you know is that there have been commits on top of
> that tag.  You can't trust the commit_id because git-describe shows
> its commit_id from master, not HEAD.  So you have to compare hashes.

That's the whole point. Git isn't SVN you can have multiple repo. And  
you can't trust an incremental count of the commit. Simply use the  
Hash, I see nothings wrong here. Do you?

> Why force someone to go through that extra step?  With every commit
> tagged you don't have to guess; you know it's a local commit.

You may trust origin, andyou can git-describe origin if you prefer.  
Looks a bit hacky too though...

>> I really think that's overkill to tag every single commit. You'll  
>> have
>> to change a bit how downstream work,
>
>    Yet again, _svnversion equivalent_.  This is how downstream worked
> the whole time x264 was on svn:  X264_VERSION reflected the number of
> commits made to svn.videolan.org.  How do you do that reliably in git
> without tagging each commit or mangling git-rev-list?


Well, fine if every commit is a release it's ok. But definitely that  
seems silly at first sight. Why is every commit a potential release. I  
bet downstream only checkout master, and sometimes if they care in  
version they just checkout master at a certain time.

Anyway, I don't have much voice here, just wanted to highlight how  
that could correctly be done.

Pierre.


More information about the x264-devel mailing list