On Tue, Dec 01, 2015 at 04:00:52PM -0500, Dave Borowitz wrote:
> On Tue, Dec 1, 2015 at 3:55 PM, Jonathan Nieder wrote:
> > Cc-ing dborowitz, who has been working on storing Gerrit's code review
> > information in Git instead of a separate database (e.g., see [1]).
>
>
Michael Haggerty wrote:
> On 11/10/2015 01:56 PM, Richard Ipsum wrote:
>> I've continued my work[1] to add patch tracking and candidate review
>> capability
>> to git.
>>
>> git-candidate now has a more git-like user interface, so remote candidates
>> can now be specified in a similar way to
On Tue, Dec 1, 2015 at 3:55 PM, Jonathan Nieder wrote:
> Cc-ing dborowitz, who has been working on storing Gerrit's code review
> information in Git instead of a separate database (e.g., see [1]).
Thanks, we actually already had a thread going that I realize only in
On Wed, Nov 11, 2015 at 03:12:05PM +, Richard Ipsum wrote:
> > All that being said, my gut feeling is that a system like this should
> > not be developed within the Git project itself. Code review is a
> > complicated thing, and I expect that different people will have very
> > different
Jeff King writes:
> On Wed, Nov 11, 2015 at 03:12:05PM +, Richard Ipsum wrote:
>>
>> The aim is not to bless one particular system but to eventually
>> provide a common data model that all review systems can share,
>> so that it is possible to do distributed reviews with
On 11/10/2015 01:56 PM, Richard Ipsum wrote:
> I've continued my work[1] to add patch tracking and candidate review
> capability
> to git.
>
> git-candidate now has a more git-like user interface, so remote candidates
> can now be specified in a similar way to remote refs (e.g. origin/candidate)
6 matches
Mail list logo