> On Jun 2, 2016, at 11:01 AM, dag at cray.com wrote: > > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> Personally, I’m hugely in favor of moving llvm’s source hosting to >>> github at some point, despite the fact that I continue to dislike >>> git as a tool and consider monotonicly increasing version numbers to >>> be hugely beneficial. >> >> Getting a monotonically increasing revision number seems doable in git >> with some server-side scripting using git notes or named tags (yet to >> be seen is how to achieve it *reliably* with github hosting). >> However the challenge is more about sharing this number across >> repositories (i.e. having clang and llvm in sync). I can imagine some >> tooling for that, but with a github hosting it may still be fragile. > > 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'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.> > 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. -- Mehdi
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
> On Jun 2, 2016, at 11:42 AM, via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > 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.+1 for branching for official llvm.org releases, and each branch should have its own linear history (from its branch point). I don’t think we want people’s random projects and development branches on llvm.org. They can clone to repo off to their own fork on github and do what they want there. -Chris