[PATCH] Detect SVN revision and path on Git working copy

Currently when building from Git `clang --version` shows Git hash and repo URL
instead of SVN revision. However SVN is master for LLVM, so it is better to
show exactly the same as if built from SVN, if we build using clean master.

Therefore we check if last commit contains git-svn-id: and if so we extract SVN
revision and repo URL. Otherwise we fallback to Git hash and URL.

Calls to sed and grep conform to POSIX standard (no extended RE).

0001-Detect-SVN-revision-and-path-on-Git-working-copy.patch (972 Bytes)

Currently when building from Git `clang --version` shows Git hash and repo URL
instead of SVN revision. However SVN is master for LLVM, so it is better to
show exactly the same as if built from SVN, if we build using clean master.

I’m not sure I follow why that is better. If I’m building from a clone of a git repo why wouldn’t I want the git hash?

Therefore we check if last commit contains git-svn-id: and if so we extract SVN
revision and repo URL. Otherwise we fallback to Git hash and URL.

This means that from build to build, depending on whether a Git change or SVN change is the most recent on my branch, I will get different results. That seems problematic.

If you're not rebasing after pulling in changes from LLVM svn, then you're going to be in for a world of pain later (I, unfortunately, speak from experience here). If you're following a git tree that has any patches on top of svn ToT then you will see a git commit as the most recent one. If you're following svn via git but don't have any local patches, then you'll get the same build if you did an svn checkout. If you do git pull from the git svn mirrors without --rebase then you're already setting yourself up for so many problems that nothing we do can really help you...

David

Mark wrote:

I’m not sure I follow why that is better. If I’m building from a clone of a git repo why wouldn’t I want the git hash?

Because SVN is a master repo, LLVM/Clang bugtracking relies on SVN revisions not Git hashes, finally you always know when some of your build are newer than others.

David wrote:

This means that from build to build, depending on whether a Git change or SVN change is the most recent on my branch, I will get different results. That seems problematic.

If you're following a git tree that has any patches on top of svn ToT then you will see a git commit as the most recent one.

@Mark: This was the idea behind this patch. If you have your own modifications you see Git repo and hash (that exists in your repo), otherwise you see SVN URL and version (as if you checked out with SVN, unless you don't rebase of coz :slight_smile:

Cheers,

If you're not rebasing after pulling in changes from LLVM svn, then you're going to be in for a world of pain later (I, unfortunately, speak from experience here). If you're following a git tree that has any patches on top of svn ToT then you will see a git commit as the most recent one. If you're following svn via git but don't have any local patches, then you'll get the same build if you did an svn checkout. If you do git pull from the git svn mirrors without --rebase then you're already setting yourself up for so many problems that nothing we do can really help you...

Maybe it will be better to detect git-svn and in such case show both
git hash and svn revision?