On Sat, Jul 2, 2016 at 3:18 AM, Tom Honermann via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> We're using tags in this manner for our internal repos and LLVM/Clang
> mirrors and haven't experienced any problems. We're at ~50k tags for
> our most used repo, so not quite at hundreds of thousands y
What doesn't scale about tagging every commit?
True, every tag creates a small file on disk, but then so does every commit.
If you're worried about lots of files in a directory then you can put tags
in nested directories by putting one or more /'s in the tag name. So you
can hide all the commit t
Bug in cmake (or more likely the makefile?), pure and simple. Version
numbers aren't strings, and they aren't floating point numbers, they are a
series of integers separated by dots. I can't think of a project where
interpreting version numbers that way won't work.
On Wed, Jun 15, 2016 at 7:21 AM,
I'd suggest a workflow like the following:
- developer commits locally to a feature/bug dev branch. You can commit
work in progress, experiments, have bad commit messages etc
- developer commits locally to a feature/bug release branch. Tidy up into a
small number of logical commits, nice messages
With submodules, the current hash of each submodule is recorded in each
master commit. If you check out a different master repository commit then
you run 'git submodule update' and it checks out the corresponding commit
in each submodule. I'm not sure why this isn't automatic with the master
repo c
