On 15/02/13 12:54, Tom Hacohen wrote: > On 15/02/13 12:27, Doug Newgard wrote: >>> On 2013-02-15 13:18, Bertrand Jacquin wrote: >>>> On 2013-02-15 13:00, Tom Hacohen wrote: >>>>> On 15/02/13 11:49, Doug Newgard wrote: >>>>>> m4/efl.m4 is still trying to call svnversion or git-svn-id to get >>>>>> the dev_version. >>>>>> >>>>>> I don't have an easy fix, git doesn't have anything quite like the >>>>>> svn revisions. >>>>>> git describe can get you the count of the number of commits since >>>>>> the last >>>>>> annotated tag, but there are no tags in the EFL git repo yet.
We could add tags to efl (and the other repos) in order to match the versioning scheme used before... For elementary and enlightenment I guess that's easy. We can choose the one commit after branching and add a tag with micro version 99 - so for elm we would git tag -a v1.7.99 61fa8b Though that screws up the whole concept of tags being releases... We'd only need that one tag, though - subsequent releases would probably happen in master so that should work fine. Looking closer at elementary the 1.7.0 tag could have actually been on the commit in master. The EFL 1.7 svn doobies commit from raster didn't add anything - it was just the actual copy operation from trunk to branches/ So that would get elm sorted out. Same with the 1.0 branch - need to rebase that to the correct version. Enlightenment is actually already okay - v0.17.0 is inside master and enlightenment-0.17 branches off after that. >>>>> Daniel and I have been trying to think about it. I say we can try to >>>>> use >>>>> git describe when it works (just get the "count after tag"), and >>>>> when >>>>> it >>>>> doesn't (i.e if there are no tags) count the commits in the history >>>>> in >>>>> order to get a count. This is not perfect, but can work. >>>>> >>>>> What do you guys think? >>>> >>>> I usually use the following to figure out the git version : >>>> >>>> git describe --tags --dirty=-dev >>>> >>>> It will give the following : >>>> >>>> stick to a tag >>>> >>>> <tagname> >>>> >>>> 10 commits after the last tag >>>> >>>> <tagname>-10-g<short last commit id> >>>> >>>> 12 commits after the last tag plus modification non commited >>>> >>>> <tagname>-12-g<short last commit id>-dev >>> >>> Also, this does not work when there is no tags at all >> >> Or when the tags are in branches, which is the case in Elementary. There > are >> tags, but none in master > > Yes. This is what we wanted to do. We actually wanted to use --always > --dirty, which means it'll work when there aren't any tags. But it's a > problem. I'll take a look into the script daniel has found. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
