On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
[snip]
>
> I'd welcome any feedback, whether on the interface and workflow, the
> internals and collaboration, ideas on presenting diffs of patch series,
> or anything else.
>
This looks awesome!
I've been working on some similar st
On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:
[snip]
>
> These definitely seem like a family of related problems. I'd like to
> use git-series as a format for storing iterations on things like GitHub
> pull-requests or Gerrit patch versions (in the latter case, overcoming
> Gerri
On Fri, Jul 29, 2016 at 09:59:08AM -0700, Stefan Beller wrote:
> On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum
> wrote:
> >>
> >> These definitely seem like a family of related problems. I'd like to
> >> use git-series as a format for storing iterations on
On Fri, Jul 29, 2016 at 06:00:55AM -0700, Josh Triplett wrote:
> On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote:
> > On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:
> > > I hope to use git notes with git-series in the future, by putting
> > >
On Mon, Aug 01, 2016 at 01:59:29AM -0700, Josh Triplett wrote:
> On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote:
[snip]
> >
> > I'm not convinced another format/standard is needed besides the
> > email workflow we already use for git and kernel development.
>
> Not all projects use a p
On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
>
> I'd welcome any feedback, whether on the interface and workflow, the
> internals and collaboration, ideas on presenting diffs of patch series,
> or anything else.
>
One other nice thing I've noticed about this tool is the
way ser
way to store
> > reviews in Git is not necessarily improving the way our code contribution
> > process works. If you want to record the discussions revolving around the
> > code, I think public-inbox already does a pretty good job at that.
I agree, and must apologise if this r
php pl pm py rst sh tcsh txt zsh
>
> But again, I do not think that it makes sense to focus too much on a
> language, or on a file format, before we came up with a strategy how to
> *not* require everybody to change their current ways.
Fair enough. :)
Thanks,
Richard Ipsum
[1]: ht
On Tue, Aug 09, 2016 at 06:22:21AM +0200, Duy Nguyen wrote:
> On Tue, Aug 9, 2016 at 12:20 AM, Michael Haggerty
> wrote:
> > On 08/04/2016 05:58 PM, Johannes Schindelin wrote:
> >> [...]
> >> Even requiring every contributor to register with GitHub would be too much
> >> of a limitation, I would
On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > > I'd welcome any feedback, whether on the interface and workflow,
On Thu, Jun 16, 2016 at 11:41:08AM +0200, Andreas Krey wrote:
> Hi all,
>
> I'm looking for pointers to review tools that work with git (obviously),
> and can deal sensibly with bigger reviews. Things we need:
>
> - Ability to split (set of) commits into multiple reviews,
> so parts of changes
ave a format that avoided creating
conflicts in the first place, but a custom merge driver doesn't seem like
an unreasonable solution.
If anyone has any thoughts on how else this problem might be solved,
I'd be very interested to hear them.
Thanks again,
Richard Ipsum
[1]: https://bi
next.
git-candidate is written in perl, with the hope that in time it
can potentially be included within contrib.
The original source repository for this project can be found
at https://bitbucket.org/richardipsum/git-candidate
Richard Ipsum (2):
contrib: Add git-candidate subcommand
contri
Describes motivation for git-candidate and shows an example workflow.
Signed-off-by: Richard Ipsum
---
contrib/git-candidate/README.md | 153
1 file changed, 153 insertions(+)
create mode 100644 contrib/git-candidate/README.md
diff --git a/contrib/git
git-candidate provides candidate review and patch tracking,
allowing distributed comment and review facilities with
all content stored in git.
Signed-off-by: Richard Ipsum
---
contrib/git-candidate/GitUtils.pm| 215 +++
contrib/git-candidate/git-candidate.perl | 2602
Describes motivation for git-candidate and shows an example workflow.
Signed-off-by: Richard Ipsum
---
contrib/git-candidate/README.md | 154
1 file changed, 154 insertions(+)
create mode 100644 contrib/git-candidate/README.md
diff --git a/contrib/git
ch as versioned metadata.
[1]: http://www.mail-archive.com/git%40vger.kernel.org/msg79461.html
Richard Ipsum (2):
contrib: Add git-candidate subcommand
contrib/git-candidate: Add README
contrib/git-candidate/GitUtils.pm| 207 +++
contrib/git-candidate/README.md | 154 ++
contri
git-candidate provides candidate review and patch tracking,
allowing distributed comment and review facilities with
all content stored in git.
Signed-off-by: Richard Ipsum
---
contrib/git-candidate/GitUtils.pm| 207 +++
contrib/git-candidate/git-candidate.perl | 2541
gt;
> I'm really excited about this tool and I think it's got great potential!
It's great to hear that, I think there is a need for a tool like this.
>
> On Tue, 2015-11-10 at 12:56 +, Richard Ipsum wrote:
> > Describes motivation for git-candidate and shows a
On Wed, Nov 11, 2015 at 10:55:07AM +0100, 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-lik
e to be able to make use of Git::Raw[2] and also ideally
the Moo framework[3].
Thanks,
Richard Ipsum
[1]:
ftp://www.kernel.org/pub/software/scm/git/docs/v2.4.0/howto/new-command.html
[2]: http://search.cpan.org/~jacquesg/Git-Raw-0.58/lib/Git/Raw.pm
[3]: http://search.cpan.org/~haarg/Moo-2.02/l
better
late than never... :)
This document is nowhere near complete. My hope is that this initial effort
helps start the conversation.
Thanks,
Richard Ipsum
[1]: https://public-inbox.org/git/20160108140831.GA10200@salo/
Network Working Group R. Ipsum
22 matches
Mail list logo
