Cleaning up VDrift source tree

[BiGBeN87]

Only 4 tags...?

These 4 were the only ones, I found on SourceForge: http://vdrift.svn.sourceforge.net/viewvc/vdrift/tags/

If we do switch to git for data, the auto-updater needs to be rewritten to use it instead of the sourceforge svn. This may be easier because git has an API, whereas the sourceforge svn code is scraping the html, although having a concept of revision number is handy.

Yes, GitHub has an API that can be accessed via HTTP:
http://developer.github.com/v3/

I would suggest the updater to consider new tags, only. Usually packages are updated with new releases, so this would be the equivalent to the usual behaviour. There is a function to list the commits of a repository, so the last tag can be identified:
http://developer.github.com/v3/git/commits/

There is a function to get information about a specific tag:
http://developer.github.com/v3/git/tags/

A tag object contains a commit object and in it is a tree object, listing the sha1s of contained blobs.

These can then be cross-referenced with the hashes returned by the VDriftDataHasher I am working on. I added object hashing that is compatible to git in:

https://github.com/bigben87/VDriftDataHa...0b31e31b87

So Git/Hub is faster at downloading for end users and patch-only developers, who can use the shallow clone.

1) What's the workflow for a patch-only developer using a shallow clone

patch-only-dev:

- initally, git clone --depth=1
- checkout master
- modify files
- git add them
- git commit them
- git format-patch origin/master..master
- create a gist containing the patche(s)
- create an issue

Examples:
- https://github.com/mootools/mootools-cor...it-Patches
- https://github.com/rakudo/rakudo/wiki/st...te-a-patch

VDrift-maintainer:

- see the issue
- download the raw patch(es) from gist
- git apply/am the patch(es)
- git push origin master

2) Is using a fork and pull request a valid workflow for the entire data tree?

I think it is, because the strict hierarchy separates commits contained in branches from each other even the forking was done some time ago and the master was not updated. I think, splitting data into individual repos for each car/track would help keeping things clear and atomic, too.

3) What's the workflow for a developer working in master? They must do a full clone, correct?

- git pull
- modify
- git add
- git commit
- git push

I would think this is the recommendable workflow, for developers/maintainers and contributors as well, because branching/merging/pull-requesting is only possible with non-shallow clones and therefore needed for agile and clean development.

In cases of more complex (read: multi-commit) projects, developers should work in branches, too and merge their work into master when they are more or less done.