[llvm-dev] New LLVM git repository conversion prototype

[Mehdi AMINI via llvm-dev]

On Thu, Dec 20, 2018 at 1:35 AM Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Dec 19, 2018 at 8:05 PM David Jones via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev <
> llvm-dev at lists.llvm.org wrote:
> >> I agree that -git or -dev could be misleading.  I also agree that we may
> >> not need this tag at all.
> >
> >
> > Strictly speaking, we don't *need* to switch to git, either. ;-)
>
> What I meant was that I don't see why we need this in order to switch
> to git. Getting nice git-describe results seems nice, but is it
> necessary? I've never used it myself, so I'm not that familiar with
> it.
>
> If we just want the ability to refer to trunk commits by number,
> couldn't we just tag the initial commit as "genesis" and git-describe
> against that?
>
> > Tagging the split point is semantically the wrong thing, though:
>
> It can't be semantically wrong if the tag correctly describes the
> commit it's applied to.
>
> That's my objection to tagging the version bump with things like
> "8.0.0-dev": the name implies that the commit is the development
> version of 8.0.0, which it's not.
>
> If we do tag the version bump, I think the name has to be something
> like "8.0.0-base" or "8.0.0-first", to correctly describe the commit
> it's tagging.
>
> > if you `git describe` the last commit before the branch for release ${N}
> (i.e., the last commit of N), the descriptor will be ${N+1} (or whatever
> tag was applied). The version bump commit will then be "${N+1}-1", meaning
> the second commit of the N+1 release (with commit hashes as appropriate).
>
> I'm having trouble following the maths here, but if we tag the
> branchpoint, say "7.0.0-branchpoint", then the commits on trunk after
> that, i.e. the development of 8, will be described as "n patches after
> 7.0.0-branchpoint" which seems entirely correct to me: version 8 is
> stuff landed after the branchpoint for 7".
>
> > An easy way to reason about this is that the version bump tag should
> only be reachable from the release branch for that version. So if the 8.0
> bump is reachable from the 7.x release branch, that's going to result in
> `git describe` attributing commits with the wrong version.
>
> I don't understand this part. Why would the 8.0 bump be reachable from
> the 7.x release branch? The version bump happens after the branch is
> created.
>
>
> Anyway, all I'm saying is that if we add tags, the name must match
> what the commit does. Tagging the version bump with "8.0.0svn" or
> "8.0.0-dev" or similar doesn't do that.
>

I see the "tagging" not much differently than the commit where we change
the version number in the CMakefile, so I would tentatively tag this bump
for consistency?

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190103/20ffb2cf/attachment.html>