[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?

[Sanjoy Das via llvm-dev]

One thing to watch out for: by default, in git, only the commit date
(and not the *push date*) is part of the commit metadata.  This means
if I write a patch today and push it two months later, the commit date
on the commit will be skewed by two months.  We could fix this using a
hook, but then the complication is that as soon as the hook changes
the commit date to `date`, the SHA-1 of the newly edited commit will
change.

I'm not a git expert though, so it could be I'm overlooking something obvious.

-- Sanjoy



On Thu, Feb 25, 2016 at 7:34 AM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 25 February 2016 at 15:01, Joachim Durchholz via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Well, PRs are a good way to discuss proposed patches, so you can take the
>> discussion there. Particularly if the git hoster gives you all the web forum
>> thingies you want, including the ability to be helpful with Markdown.
>> Also, a PR is easy to integrate once it's done.
>
> Phabricator, for better or worse, has all those qualities.
>
>
>> On the git side of things, you need to make sure that history isn't
>> rewritten official branches such as master.
>
> Someone mentioned server-side hooks, I think that settles the problem.
>
>
>> On many projects, people still go through PRs even if they have direct write
>> access. Simply to make sure that a second pair of eyes have looked at the
>> code before it goes in.
>
> With the amount of commits we have (~100 / day), that would be
> impossible. But we still do that with Phab on the more complicated
> bits.
>
> We're aware of the benefits of code review, etc. I was wondering if
> you had some technical issues with git not being suitable. It seems
> there isn't anything particularly broken, that some hooks can't fix.
>
>
>> For that, public git hosting services are a no-brainer.
>> You need to look at permissions because you can't simply set up gitolite,
>> you have to live with whatever the service offers.
>
> That's a small cost, I'd say. And we can always move providers later
> on, which is a lot simpler with git than SVN.
>
>
>> The GitHub "flow" isn't the right one for every project, so the tooling does
>> matter.
>
> As a first step, we're not planning on following the GitHub flow, just
> using the GitHub storage and bandwidth. :)
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
Sanjoy Das
http://playingwithpointers.com