[llvm-dev] New LLVM git repository conversion prototype

[James Y Knight via llvm-dev]

On Fri, Nov 16, 2018 at 5:46 PM David Jones <dlj at google.com> wrote:

> Hi James,
>
> I've started working with the prototype layout in context of Google's
> internal infrastructure. With deep apologies, I have a (very late, I know)
> pair of requests that have only recently solidified for me.
>

Changing the set of, the names of, or in many cases, even the contents of,
the tags/branches in the repository is going to be significantly less
intrusive than changing commit hashes on trunk. I don't think it's at all
too late to have this discussion. (Although, before engaging too much more
in making changes, I'd _really_ like to finally resolve the zippered
repository alternative thread, which decides whether all this gets entirely
discarded...)


> 1. Could you add annotated tags after the cut point of each release? (I
> think this would probably be easy.)
>

The tags and commits in the repository right now are migrated from
subversion. If we want additional tags around releases, the most
straightforward way to do that will be to add the tags we want in svn (once
we decide what we want).


> 2. Could you mark branch/tag operations somehow other than a annotated tag
> on master? (This seems less trivial, but my reasoning is below.)
>

Only subversion copies, to the "*/tags/*" hierarchy, which don't have any
changes to their content after the copy (e.g. commits made to the "tag"),
get converted from a git branch into a git annotated tag. That entire
tag-conversion process could easily be scrapped, leaving everything as a
git branch (named svntag/*). But I think that is not a good idea in general
-- e.g., the RELEASE_701/rc2 tag on the release_70 branch really does
function best as an annotated tag.

That said, I do think most of the branches and tags in the repository
should be moved to an "llvm-historical-branches" repository (or something
like that), which most people will ignore, but is available for those who
want to go digging through historical artifacts. After the git migration,
people will most likely make their own non-release branches and tags in
their own git forks published in their own github accounts, not in the
primary llvm repository.

We do still need to select which branches/tags to retain in the primary
repository -- I haven't thought much about this, beyond that it should be
less than everything, and should have at least the releases branches and
tags.


> The overall goal is for `git describe` to give a reasonable default output.
>

>
> Reasoning for request #1:
>
> Example: add a tag after the cut point of the 7.0 release:
>
> $ git log --oneline $(git merge-base HEAD origin/release_70)..HEAD | tail
> -1
>

Sidenote: this can be more simply spelled:
 $ git log --oneline origin/release_70..HEAD | tail -1
if you recall that "X..Y" is simply a shortcut for "^X Y" (that is: all
commits reachable from Y, excluding those reachable from X; so X having
additional branch commits that aren't on master makes no difference).


63297479398 Bump the trunk version to 8.0.0svn
> $ git tag -m 'Begin development of 8.0.0.' '8.0.0svn' 63297479398
>
> Then, `git describe` can give a useful result that would be stable(-ish
> [*]):
>
> $ git describe --match=\*svn
> 8.0.0svn-7878-gfdb08034fd8
>
> ([*] Subject to the normal caveat for git-describe: the trailing short
> hash may become non-unique over time. This is mentioned in the git help.)
>
> Again, I think these tags could probably be added later, but it would be
> nice to have a single source of truth (especially since the tag annotation
> is itself a commit).
>
> I think we could also probably come up with better than than '8.0.0svn';
> although whatever the choice, they probably need to be suitable for
> --match, because...
>

We could name tags named something like: "v8.0dev" (for trunk tag),
"v8.0.0rc1" (after making a branch and updating the version numbers in the
branch), "v8.0.0" (for the final release from the branch). And, use
--match="v*" in the describe output. I think this basically obviates the
need for request #2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181116/96f7f1fd/attachment.html>