On 8 July 2016 at 20:12, Chris Matthews wrote:
> If LNT is the only holdout I suggest we update the LNT model to natively
> handle git.
I could say the reverse... If improving LNT is a reason to move to
Git, than we should do it. :)
> This sort of change to the
> guts of how LNT works is weeks
On 8 July 2016 at 21:07, Mehdi Amini wrote:
> The problem is not that is it is not possible to work with a tuple (branch,
> number), the problem is that a tuple (or a string) is not a number and breaks
> existing infrastructure. It does not mean it cannot be made to work, but it
> won’t out-of-
> On Jul 8, 2016, at 1:05 PM, Renato Golin wrote:
>
> On 8 July 2016 at 21:04, Mehdi Amini wrote:
>>> What about git describe?
>>
>> Not a number.
>
> It contains a number... "tag-number-hash"
>
> Removing the tag and hash seems trivial.
And you end up with a number that is not unique acros
On 8 July 2016 at 21:04, Mehdi Amini wrote:
>> What about git describe?
>
> Not a number.
It contains a number... "tag-number-hash"
Removing the tag and hash seems trivial.
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.o
> On Jul 8, 2016, at 1:03 PM, Renato Golin wrote:
>
> On 8 July 2016 at 17:45, Mehdi Amini wrote:
>> You missed the point that in a single instance of LNT a revision number has
>> to be unique.
>> The rev-list thing won't provide this across branches.
>> A rev-list count number won't identify
On 8 July 2016 at 17:45, Mehdi Amini wrote:
> You missed the point that in a single instance of LNT a revision number has
> to be unique.
> The rev-list thing won't provide this across branches.
> A rev-list count number won't identify a revision, you need the tuple
> (branch, count), which is l
With svn the the IDs are unique in, so r123 implies a branch. svn log
—revision=123:234 give the right change list when svn is directed at that
branch. So right now, I can get the change list in one command easily without a
script.
llvmlab bisect already encodes branch information in the build
Sent from my iPhone
> On Jul 8, 2016, at 9:18 AM, Renato Golin wrote:
>
>> On 8 July 2016 at 03:14, Robinson, Paul wrote:
>> I could see wanting to compare data from master and a release branch. If
>> that means sequential IDs need to work across branches, then we're back to
>> needing a fan
On 8 July 2016 at 03:14, Robinson, Paul wrote:
> I could see wanting to compare data from master and a release branch. If
> that means sequential IDs need to work across branches, then we're back to
> needing a fancier solution than 'rev-list –count'.
How would you do this in SVN anyway?
Branch
I could see wanting to compare data from master and a release branch. If that
means sequential IDs need to work across branches, then we're back to needing a
fancier solution than 'rev-list –count'.
--paulr
From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Chris
Matthews via
On 7 July 2016 at 17:56, Chris Matthews via llvm-dev
wrote:
> With both llvmlab and LNT, once you get to a range of IDs, it is needs to be
> easy to find out what commits or commit range those IDs map to.
Making no comment on how easy or hard it will actually be, doesn't it
just have to be possib
11 matches
Mail list logo
