[llvm-dev] New LLVM git repository conversion prototype

[David Jones via llvm-dev]

On Fri, Nov 16, 2018 at 3:54 PM James Y Knight <jyknight at google.com> wrote:

> 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).
>
>

I can certainly do that... this strategy doesn't really make sense from the
Subversion side (but I suppose that's fine for conversion purposes).


> 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.
>

Side note: on a release branch, that's fine... it doesn't cause problems on
master since that tag doesn't point to a commit reachable from master/HEAD.
The problem is when annotated tags are reachable from master.


>
> 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/ba45546a/attachment.html>