[lldb-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes:

>> What exactly is the concrete benefit of monotonically increasing
>> revision numbers?  It's completely foreign to git's architecture.
>
> I'm notified that bug is fixed in r12345, my binary says "clang -v" is
> r23456, if I observe the bug I know there is a problem immediately.
> Another use case is that it provides a cross-repository reference.

I know this is just one example, but the clang version number can be set
to whatever we want to set it to.  It can include the most recent commit
date, for example.

My larger point is that in git, there is no time-based relationship
among commits if there are branches and merges, so a
monotonically-increasing number is misleading.

> I'm sure that if you lookup the previous discussion about moving to
> git (two years ago, and four years ago I believe), the threads contain
> plenty of arguments from people attached to it.
> I don't want to play the "devil's advocate" here since I'm not that bothered by loosing this.

Sure.  And I'm sure there are use-cases I'm not familiar with.  I'm
simply asking the question because in my experience managing a gigantic
migration of our codebase, a move to git usually raises a bunch of
assumptions by people that may or may not actually be accurate.

A move to git (or any other revision system, really) is an opportunity
to re-examine workflows and assumptions.

>> Putting this requirement on git is going to severely limit how the
>> history is allowed to look.  Maybe that's what people want, I don't
>> know.  We certainly haven't missed them since moving to git.
>
> I'm personally fine with arbitrary history in git, but some people (I
> suspect many here) are attached to the linear history.
> So my impression is that such a move has more chances of being
> accepted by the community if we keep the same workflow (linear history
> + monotonic revision numbers), at least at first.

Yeah, I get that and I actually don't mind keeping a linear history.
But we definitely should branch for release.  Given release branches,
there are a number of questions and tradeoffs about how to backport
changes from master/latest development to a release.  Some of those
options break linear history.  This is the kind of workflow stuff we
should clarify if possible.

                             -David