<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 3:54 PM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>On Fri, Nov 16, 2018 at 5:46 PM David Jones <<a href="mailto:dlj@google.com" target="_blank" class="cremed">dlj@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi James,</div><div><br></div>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.</div></div></div></div></div></div></div></blockquote><div><br></div><div>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...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">1. Could you add annotated tags after the cut point of each release? (I think this would probably be easy.)</div></div></div></div></div></div></div></blockquote><div><br></div>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).<br class="m_-1817490092105888828gmail-Apple-interchange-newline"><div> </div></div></div></div></div></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div><div dir="ltr">2. Could you mark branch/tag operations somehow other than a annotated tag on master? (This seems less trivial, but my reasoning is below.)</div></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The overall goal is for `git describe` to give a reasonable default output.</div></div></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div><br></div><div>Reasoning for request #1:</div><div><br></div><div>Example: add a tag after the cut point of the 7.0 release:</div><div><br></div><div><div>$ git log --oneline $(git merge-base HEAD origin/release_70)..HEAD | tail -1</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Sidenote: this can be more simply spelled:</div><div><div> $ git log --oneline origin/release_70..HEAD | tail -1</div></div><div><div>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). </div><br class="m_-1817490092105888828gmail-Apple-interchange-newline"></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>63297479398 Bump the trunk version to 8.0.0svn</div></div><div>$ git tag -m 'Begin development of 8.0.0.' '8.0.0svn' 63297479398</div><div><br></div><div>Then, `git describe` can give a useful result that would be stable(-ish [*]):</div><div><br></div><div>$ git describe --match=\*svn<br></div><div><div>8.0.0svn-7878-gfdb08034fd8</div></div><div><br></div><div>([*] 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.)</div><div><br></div><div><div>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).</div><div><br></div><div>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...</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div></div></div></div></div>
</blockquote></div></div>