[llvm-dev] [7.0.0 Release] The release branch is open; trunk is now 8.0.0

[Martin J. O'Riordan via llvm-dev]

Thanks Tim,

I think that what I want is to track the development of the v7.0.0 release as I would previously with SVN using the head of the branch, so the current state of the branch is most relevant to me.  But I also periodically like to go to a particular SVN revision on the main development sources for legacy reasons - most of my workflow for LLVM development evolved on SVN.  Usually, when the branch is created, I like to archive the state of the main development sources at the revision noted in Hans Wennborg's' branch announcement (in this case r338536).

What I see now (after 'git merge-base master origin/release_70' and 'git pull') is:

  $ git branch --list
  * master
    martino

  $ git tag
  RELEASE_400/final
  RELEASE_401/final
  RELEASE_500/final
  RELEASE_501/final
  prerelease_20180108
  release_600
  release_601

My image was initialised with:

  git -v clone https://github.com/llvm-project/llvm-project-20170507/ llvm-project

but I don't see a v7.0.0 specific tag or branch - is it the 'prerelease_20180108' tag?  I successfully found the commit corresponding to the SVN tag for r338536 following your instructions as:

  commit 1c1bb329bdac77e048f7831a7dded3c61021be9f
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   Wed Aug 1 13:24:39 2018 +0000

      [dsymutil] Convert recursion in lookForDIEsToKeep into worklist.
    
      The functions `lookForDIEsToKeep` and `keepDIEAndDependencies` can have
      some very deep recursion. This tackles part of this problem by removing
      the recursion from `lookForDIEsToKeep` by turning it into a worklist.
    
      The difficulty in doing so is the computation of incompleteness, which
      depends on the incompleteness of its children. To compute this, we
      insert "continuation markers" into the worklist. This informs the work
      loop to (re)compute the incompleteness property of the DIE associated
      with it (i.e. the parent of the previously processed DIE).
    
      This patch should generate byte-identical output. Unfortunately it also
      has some impact of performance, regressing by about 4% when processing
      clang on my machine.
    
      Differential revision: https://reviews.llvm.org/D48899

  Notes:
      git-svn-rev: 338536

Your response (I think) answers both of these requirements, thanks very much for helping with my GIT newbie limitations.  

All the best,

    MartinO

-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: 03 August 2018 12:08
To: Martin J. O'Riordan <MartinO at theheart.ie>
Cc: Hans Wennborg <hans at chromium.org>; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [7.0.0 Release] The release branch is open; trunk is now 8.0.0

On Fri, 3 Aug 2018 at 11:42, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> A few months ago I switched from using SVN for the LLVM project to 
> using the GIT mono-repo, but I am still not particularly good at using 
> GIT.  How can I use the GIT command-line interface to select to the 
> exact same set of sources used for the v7.0.0 branch,

Do you mean the commit that was forked to create the 7.0 branch, the commit that was released as 7.0.0, or the current status of the 7.0 branch? In turn they'd be:

1. git merge-base master origin/release_70 2. These are stored as tags I believe, though the format has changed and we only started recently. "git tag" lists what we have now, with an obvious mapping to releases (for a human).
3. Just plain origin/release_70

> or for the sources at a particular SVN revision (e.g. r338536)?

For now, svn revisions are stored in notes attached to each git commit. Annoyingly they're not downloaded by default so you have to run this once:

$ git fetch origin refs/notes/*:refs/notes/*

After that they'll come along with every "git fetch" or "git pull".
Once you have those, I personally just grep a "git log" for a revision I'm interested in. You could package some variant of

$ git log --grep "git-svn-rev: 338839" -1

into a script pretty easily though.

Cheers.

Tim.