[llvm-dev] New LLVM git repository conversion prototype

David Greene via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 13 11:25:51 PST 2018

David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes:

>     v8.0.0-branchpoint might be even clearer, though obviously a
>     little longer.
> Whatever the convention we choose, it's going to be painful to change
> once folks get used to it. (So the wording of the tag is not entirely
> inconsequential.) My expectation is that the `git describe` aliases
> will be the typical way to refer to commits in a git world, and
> aliases like v8.0.0-branchpoint-1234-abcdef seem a bit long to me...
> when I think about how often I type "rNNNNNN" today, the
> "-branchpoint" part seems almost obsequious.

FWIW we use "split" to mark such commits.  So it would be v8.0.0-split.
But see below.

> For a development tag, we should probably try to keep it short,
> simple, and obvious. After all, we're fundamentally talking about a
> tag used for development, not releases; something short, like
> "master-v8" would yield concise, obvious aliases like
> "master-v8-1234-abcdef01". (Tags on release branches are a
> fundamentally different matter, and could continue looking exactly
> like they do today.)

"master" could be confusing for downstream.  For example we have a setup
where our development happens on "master" and we have a branch called
"upstream_master" to pull from upstream.  It would be confusing to see a
tag called "master" on a branch not named "master."

"v8.0.0-split/dev/branchpoint/whatever" could also be confusing to
downstream as it could conflict with downstream named tags if their
products happen to have version number conflicts.  Follwing Duncan's
suggestion, would llvm.org-8.0.0-split (or suggest some other suffix)
work?  I know it's longer but it would be unambiguous.

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes:

> I have a mild preference for "llvm.org-8.0.0" (instead of
> "llvm-8.0.0"), since llvm.org is unambiguously a point of origin,
> whereas "llvm" could just refer to the content. E.g., some downstreams
> might package their product with the name "llvm".

I have a slight preference for that too, for the same reasons.


More information about the llvm-dev mailing list