[llvm-dev] GitHub anyone?
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 2 11:06:02 PDT 2016
> 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
More information about the llvm-dev
mailing list