As for pull requests, you can still split it up into multiple commits, then when you do the final pull request, it includes all those little commits, just as if they'd been made on the master branch.
]]>my github: https://github.com/iZsh
]]>Some suggestions about compiling under Windows ? (I would like that version is present inside firmware .elfs).
As usual. Just compile.
Perhaps my post earlier was a bit too hasty and compressed. Another try:
I have now fixed the mkversion.pl-script, so that it uses the git-versioning information instead of svn-version. It would be great if someone were to test that on different platforms (windows and mac). Either compile or just run 'perl tools/mkversion.pl' and see if it looks correct .
I also added a version tag (or rather, two) to the github codebase. Earlier, we had "implicit" versioning with svn revision numbers, which we don't anymore - now a dev needs to explicitly tag a version. My command was just to document how to do that. We should port the HACKING.txt to a github wiki page instead, and include some basic git-handling (e.g. versioning).
Also, after I was finished, it dawned on me that I'd probably caused a bug: https://github.com/Proxmark/proxmark3/issues/10 . Haven't had time to look at it yet.
]]>How to versionize:
git tag -a v1.0.1 -m 'Version 1.0.1' && git push --tags
#git describe --dirty && git symbolic-ref HEAD
v0.8.8-1-g9969116-dirty
refs/heads/ioprox_fixes
vs
#git describe --dirty && git rev-parse --abbrev-ref HEAD
v0.8.8-1-g9969116-dirty
ioprox_fixes
Sure, let's use the latter.
]]># git symbolic-ref HEAD
refs/heads/master
EDIT:
Better use "git rev-parse --abbrev-ref HEAD"
# git rev-parse --abbrev-ref HEAD
master
Git declares repos as dirty if they have any modified files or untracked files.
Hm, not quite, untracked files do not show up:
#git describe --all --dirty
heads/ioprox_fixes
#touch test.txt
#git describe --all --dirty
heads/ioprox_fixes
I think we should include it. Normally, things won't be dirty, but if someone modified something it'll show up. If they modified, committed (locally), it will should also show up according to doegox (unless I'm misinterpreting that), but on my test-branch I don't have any versions yet, so I guess that's why I don't see that below:
#git describe --all --dirty
heads/ioprox_fixes
#git add test.txt
#git commit -m "foo"
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
#git describe --all --dirty
heads/ioprox_fixes
More testing, with versioning:
#git tag -a v0.8.8 -m "Testversion"
#git describe --all
v0.8.8
#echo "x" > test.txt
#git add test.txt && git commit -m "foobar"
1 file changed, 1 insertion(+)
#git describe --all --dirty
heads/ioprox_fixes
#git describe --dirty
v0.8.8-1-g9969116
#git describe
v0.8.8-1-g9969116
#echo "x" >> HACKING.txt
#git describe
v0.8.8-1-g9969116
#git describe --dirty
v0.8.8-1-g9969116-dirty
So, my testing shows that 'git describe --dirty' works ok if we're on main branch and have a version tag somewhere behind us. However, it does not show the branch name we are on. But perhaps it works well enough for our purposes?
]]>Didn't get that exact syntax working (without options to describe), but this could do:
#git describe --all --dirty heads/ioprox_fixes #echo "x" >> HACKING.txt #git describe --all --dirty heads/ioprox_fixes-dirty
Ahhh. A clean git is a git repository with no changes and an unclean (dirty) repo is a git repository with changes that are not committed, right?
EDIT:
I don't see why we should include this flag (dirty). Git declares repos as dirty if they have any modified files or untracked files.
If I develop my own proxmark features I will get the latest version from the master branch, create my own branch and work there.
I will make commits and update the .gitignore. So at least for my development process I will never get a dirty branch.
(And I think this process is very common.) In svn clean/unclean is useful because you can't create local, private branches. But on
git this is possible. In your local branch you do commits like any other developer therefore the branch should never be dirty.
But anyways, adding "--dirty" to "git describe" wont harm us , it will just append "-dirty".
[change something and do not commit it]
# git describe --dirty
libnfc-1.7.1-10-gbd92f74-dirty
Versioning should be at least 0.8.52, (since we branched off around revision 852).
I don't want to start at 0.0.1 ether, but starting a 0.8.52 seems wrong too. We agreed on using Semantic Versioning
and therefore the numbers have a meaning:
Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.
0.8.52 has nothing to do with Semantic Versioning, is just an adoption of the svn revision number.
Maybe we should start at 1.0.0 (this is common for the first release) but I'm open to other suggestions.
]]>