I really liked the the solution proposed earlier in this thread: Do nothing
server side, but instead use
`git rev-list --count master` on the client side (which takes 0.9s on my
machine) to get the number of the commit. So nothing to do on the ID part IMO.
As for updating the meta repository: We
On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth
wrote:
> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> I also believe this is the simplest versioning scheme*. It eliminates all
>> future debates on this topic (e.g, when to bump major vers
On 26 June 2016 at 23:02, Anton Korobeynikov wrote:
> Does github allow this? IIRC their support for server-side hooks was
> very limited due to obvious reasons. And executing hooks e.g. on
> llvm.org seems very error-prone.
Someone suggested it was possible. I have sent them an email with a
draf
> 1. Control the history via server hooks updating a unique and
> auto-increment identifier, which will apply to every commit on its
> submodules (ie, every other LLVM project).
Does github allow this? IIRC their support for server-side hooks was
very limited due to obvious reasons. And executing
So,
It's been a while and the GitHub thread is officially dead, so I'll
propose a development methodology based on the feedback from that
thread. This is not *my* view, but all that was discussed in the
threads.
My objective is to form an official proposal to use Git as our main
repository, overc
On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> I also believe this is the simplest versioning scheme*. It eliminates all
> future debates on this topic (e.g, when to bump major version etc) and
> solves the problem once and for all -- which is an
I also believe this is the simplest versioning scheme*. It eliminates all
future debates on this topic (e.g, when to bump major version etc) and
solves the problem once and for all -- which is another plus :)
*) similar suggestions a) start from 4, increase by 1; b) start from 40,
increase by 1.
I also support Chris's position of 4.0, 4.1 etc. I don't think "majorness"
is that important, and we can sort out the bit code compatibility story
some other way.
Sent from phone
On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
llvm-...@lists.llvm.org> wrote:
> On Mon, Jun 13, 2016 at 4:54
