"Jeff Squyres (jsquyres)" <jsquy...@cisco.com> writes: > The ompi repo only contains the master branch. Releases are not made > from master, and therefore it doesn't make sense to tag it with > release tags. master is therefore not (directly) related to any given > release.
You can have tags in the repository without the branches, though I think it's useful for a contributor to git checkout -b my/bug-fix maint-1.8 instead of making a patch off 'master' that needs to be back-ported to the release. The usual model is that one merges "upward" from the maintenance branches to 'master'. But regardless, isn't it valuable to be able to query things like this? git log v1.8.0..master ompi/mpi/c/iallreduce.c git branch -r --contains $bug_fix_commit Seems to me that most people cloning open-mpi/ompi will want to fetch From open-mpi/ompi-release regularly so they can have this context. > The "dev" tag is there so that we can make nightly tarballs with a > logical sequence (via "git describe"). The "dev" tag is basically > there as the point at which we converted to git. We could have put it > back at the beginning of time (i.e., equivalent to SVN r1 (i.e., the > first CVS commit!)), but it didn't really matter, so we just opted for > a dev that resulted in a smaller "git describe" number. That number will get big later and it deprives you of context when you have no idea whether "dev-BIGNUMBER" is earlier or later than a given release. (Does it have those features/bugs or not?)
pgpWLBl3jKfrr.pgp
Description: PGP signature
