Josh Triplett writes:
>> But submission is less important than review. And for review it is
>> usually better (except gigantic series) to have patch text for review
>> with the review.
>
> Agreed. However, submission typically requires more work than review,
> because the patch text must remain
On 10 August 2016 at 02:55, Josh Triplett wrote:
> On Tue, Aug 09, 2016 at 06:28:00PM +, Eric Wong wrote:
>> Some of these problems I hope public-inbox (or something like
>> it) can fix and turn the tide towards email, again.
>
> This really seems like the dichotomy that drives people towards
On Wed, Aug 10, 2016 at 09:30:01AM +0200, Jakub Narębski wrote:
> On 10 August 2016 at 02:55, Josh Triplett wrote:
> > On Tue, Aug 09, 2016 at 06:28:00PM +, Eric Wong wrote:
> >> Some of these problems I hope public-inbox (or something like
> >> it) can fix and turn the tide towards email, aga
Josh Triplett wrote:
> On Tue, Aug 09, 2016 at 06:28:00PM +, Eric Wong wrote:
> > Some of these problems I hope public-inbox (or something like
> > it) can fix and turn the tide towards email, again.
>
> This really seems like the dichotomy that drives people towards central
> services like G
On Tue, Aug 09, 2016 at 06:28:00PM +, Eric Wong wrote:
> Some of these problems I hope public-inbox (or something like
> it) can fix and turn the tide towards email, again.
This really seems like the dichotomy that drives people towards central
services like GitHub or GitLab. We need an alter
On Tue, Aug 09, 2016 at 06:57:05AM -0400, Jeff King wrote:
> On Tue, Aug 09, 2016 at 10:11:30AM +0200, Michael J Gruber wrote:
>
> > Maybe two more points of input for the discussion:
> >
> > off-line capabilities
> > =
> >
> > The current workflow here seems to work best whe
Jeff King writes:
> On Tue, Aug 09, 2016 at 10:34:11AM -0700, Junio C Hamano wrote:
>
>> It may be a good UI that is optimized for drive-by contributors. It
>> is just that it is not very well suited (compared to mailing list
>> discussions) to conduct high-volume exchange of ideas and changes
>
On Tue, Aug 09, 2016 at 11:50:51AM -0700, Stefan Beller wrote:
> > Could you share your mutt set up pleaaase? I've been wanting this for
> > a long time, but never used mutt long enough to bother with a proper
> > setup like this (I blame gmail).
>
>
> That is my complaint^H^H^H^H position, too.
On Tue, Aug 09, 2016 at 08:43:59PM +0200, Duy Nguyen wrote:
> On Tue, Aug 9, 2016 at 1:37 PM, Jeff King wrote:
> >That's (relatively) easy for me to script via mutt (grab
> >these patches, apply them).
>
> Could you share your mutt set up pleaaase? I've been wanting this for
> a long tim
On Tue, Aug 9, 2016 at 11:43 AM, Duy Nguyen wrote:
> On Tue, Aug 9, 2016 at 1:37 PM, Jeff King wrote:
>>That's (relatively) easy for me to script via mutt (grab
>>these patches, apply them).
>
> Could you share your mutt set up pleaaase? I've been wanting this for
> a long time, but never
On Tue, Aug 9, 2016 at 1:37 PM, Jeff King wrote:
>That's (relatively) easy for me to script via mutt (grab
>these patches, apply them).
Could you share your mutt set up pleaaase? I've been wanting this for
a long time, but never used mutt long enough to bother with a proper
setup like thi
On Tue, Aug 9, 2016 at 8:36 PM, Duy Nguyen wrote:
> On Tue, Aug 9, 2016 at 1:20 AM, Michael Haggerty wrote:
>> Could you elaborate why you would expect quality and/or quantity of
>> reviews to suffer? I'm really curious, and I'd be happy to pass your
>> feedback along to my colleagues.
>
> Since
On Tue, Aug 9, 2016 at 1:20 AM, Michael Haggerty wrote:
> Could you elaborate why you would expect quality and/or quantity of
> reviews to suffer? I'm really curious, and I'd be happy to pass your
> feedback along to my colleagues.
Since I have been using github at work for a couple months, I do
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 wager.
> > [...]
> * Discussion of pull requests can be done either
> * via the website (super easy
On Tue, Aug 09, 2016 at 10:34:11AM -0700, Junio C Hamano wrote:
> >The threading in GitHub comments and pull requests is also not great.
> >Each PR or issue is its own thread, but it's totally flat inside.
> >There are no sub-threads to organize discussion, and it's sometimes
> >ha
Jeff King writes all what I wanted to say, and a lot
more, so I don't have to say much ;-)
> - I really like the flow of having conversations next to patches. I can
>look at the index of the mailing list folder and see what people are
>talking about, how big the threads are, etc, at a gl
Johannes Schindelin writes:
> On Mon, 8 Aug 2016, Junio C Hamano wrote:
>
>> Unless a patch is about an area you are super familiar with so that you
>> know what is beyond the context of the patch to be able to judge if the
>> change is good in the context of the file being touched, it is always
Hi Michael,
On Tue, 9 Aug 2016, 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 wager.
> > [...]
>
> Is it *really* so insane to consider moving coll
Jakub Narębski venit, vidit, dixit 09.08.2016 10:24:
> On 9 August 2016 at 10:11, Michael J Gruber wrote:
>
>> My own setup
>>
>>
>> My usual MUA is Thunderbird because of its integration with calendars
>> and address books. I usually read and post to mailing lists via
>> nntp/gmane,
Hi Junio,
On Mon, 8 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I think you both got it wrong. The original citizens were the mail
> > clients that allowed you to communicate with other human beings.
> > ... It is our usage to transport machine-readable content (and not
Hi Junio,
On Mon, 8 Aug 2016, Junio C Hamano wrote:
> Lars Schneider writes:
>
> > 4.) Reviewing patches is super hard for me because my email client
> > does not support patch color highlighting and I can't easily expand
> > context or look at the history of code touched by the patch (e.g via
On Tue, Aug 09, 2016 at 01:20:05AM +0200, Michael Haggerty wrote:
> > but I
> > do not think it is sane to expect that the same quality and quantity
> > of reviews as we do here can be maintained with that thing.
>
> Could you elaborate why you would expect quality and/or quantity of
> reviews to
On Tue, Aug 09, 2016 at 10:11:30AM +0200, Michael J Gruber wrote:
> Maybe two more points of input for the discussion:
>
> off-line capabilities
> =
>
> The current workflow here seems to work best when you are subscribed to
> the git-ml and have your own (local, maybe select
On Tue, Aug 09, 2016 at 10:17:22AM +0100, Richard Ipsum wrote:
> > In the very unlikely event that github is shut down, how do we get all
> > review comments out of it, assuming that we will use pull requests for
> > review?
>
> For what it's worth this is exactly why I think it would be worthwhi
On 08/09/2016 06:22 AM, 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 wager.
>>> [...]
>>
>>
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 9 August 2016 at 10:11, Michael J Gruber wrote:
> My own setup
>
>
> My usual MUA is Thunderbird because of its integration with calendars
> and address books. I usually read and post to mailing lists via
> nntp/gmane, that works best for me for several reasons (e.g. archive
> ava
Michael Haggerty venit, vidit, dixit 09.08.2016 01:20:
> Given that I work for GitHub, I'm uncomfortable doing any more advocacy
> here. If people have concrete questions, I'd be happy to answer them, on
> the list or in private.
You're doing a great job differentiating between your roles as a mem
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 wager.
>> [...]
>
> Is it *really* so insane to consider moving collabora
On 08/09/2016 12:36 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Is it *really* so insane to consider moving collaboration on the Git
>> project to GitHub or some other similar platform?
>
> I only know how "pull requests" and "issues" discussion in GitHub
> Web interface _currently
Michael Haggerty writes:
> Is it *really* so insane to consider moving collaboration on the Git
> project to GitHub or some other similar platform?
I only know how "pull requests" and "issues" discussion in GitHub
Web interface _currently_ looks like, so if you have even more
wonderful thing in
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 wager.
> [...]
Is it *really* so insane to consider moving collaboration on the Git
project to GitHub or some other similar platform?
Lars Schneider writes:
> ... then I am always super
> eager to send out a new roll just because I don't want any other reviewer
> to waste time on obviously wrong patches. However, I have the impression
> that frequent re-rolls are frowned upon.
Correct. A good middle-ground is
Johannes Schindelin writes:
> I think you both got it wrong. The original citizens were the mail
> clients that allowed you to communicate with other human beings.
> ... It is our usage to transport machine-readable content (and not
> as an attachment!) that is the intruder.
It is not "its is ou
> On 06 Aug 2016, at 10:58, Johannes Schindelin
> wrote:
>
> Hi Stefan,
>
> just quickly (i.e. addressing only one point, will try to address more at
> a later date) because I want to be mostly offline this weekend:
>
> On Fri, 5 Aug 2016, Stefan Beller wrote:
>
>> On Fri, Aug 5, 2016 at 1:2
Hi,
On Sat, 6 Aug 2016, Eric Wong wrote:
> Junio C Hamano wrote:
> > Somebody mentioned "configuring it is hard--why does the user have
> > to know SMTP subtleties", and that may be a valid complaint against
> > the primary part of send-email. The solution for that is not to
> > discard it with
Hi Stefan,
just quickly (i.e. addressing only one point, will try to address more at
a later date) because I want to be mostly offline this weekend:
On Fri, 5 Aug 2016, Stefan Beller wrote:
> On Fri, Aug 5, 2016 at 1:20 AM, Johannes Schindelin
> wrote:
> >
> > I also hate to break it to you tha
Hi Philip,
On Fri, 5 Aug 2016, Philip Oakley wrote:
> In the same vein, I always want,with my workflow, to use "fixup!
> ".
Good news for you: this is already supported. See here:
https://github.com/git/git/blob/v2.9.2/git-rebase--interactive.sh#L786-L796
Ciao,
Dscho
--
To unsubscribe from thi
Hi Eric,
On Fri, 5 Aug 2016, Eric Wong wrote:
> Johannes Schindelin wrote:
> > On Thu, 4 Aug 2016, Stefan Beller wrote:
> > > git send-email/format-patch recently learned to include a base commit
> >
> > You may have noticed that my mail-patch-series.sh-generated code
> > submissions contain th
Junio C Hamano wrote:
> Somebody mentioned "configuring it is hard--why does the user have
> to know SMTP subtleties", and that may be a valid complaint against
> the primary part of send-email. The solution for that is not to
> discard it with bathwater, but make it just as easy as other MSAs,
>
From: "Johannes Schindelin"
Hi Philip,
On Fri, 5 Aug 2016, Philip Oakley wrote:
In the same vein, I always want,with my workflow, to use "fixup!
".
Good news for you: this is already supported. See here:
https://github.com/git/git/blob/v2.9.2/git-rebase--interactive.sh#L786-L796
That's
On Fri, Aug 05, 2016 at 05:24:14PM +0200, Johannes Schindelin wrote:
[snip]
> >
> > This "unified review storage format" really does seem to be the missing
> > piece.
>
> FWIW I do not think so. The real trick will be to come up with an
> improvement to the process that lets Junio and Peff contin
Johannes Schindelin writes:
> The problem is not Perl, but how fiddly it is to set up. And that you lose
> all the niceties of an email client (e.g. when you want to add a comment
> before the diff stat that is not intended to become a part of the commit
> message).
Just this part. I do not thi
Stefan Beller wrote:
> On Fri, Aug 5, 2016 at 1:20 AM, Johannes Schindelin
> wrote:
> > Yet another option would be to have a tool that integrates with the Git
> > repository of the Git mailing list represented by public-inbox.
>
> So my first reaction to that would be: you could push you patche
On Mon, Sep 17, 2001 at 10:00:00AM +, Stefan Beller wrote:
> But both send-email as well as mail-patch-series as well as git-series
> are all about the *sending* part. Not about the back and forth part, i.e.
> these don't deal with: "here is a fixup on top". And by that I mean
> receiving mails
Johannes Schindelin wrote:
> On Thu, 4 Aug 2016, Stefan Beller wrote:
> > git send-email/format-patch recently learned to include a base commit
>
> You may have noticed that my mail-patch-series.sh-generated code
> submissions contain that base commit. But they still do not contain the
> SHA-1s o
From: "Duy Nguyen"
On Wed, Aug 3, 2016 at 6:07 PM, Johannes Schindelin
wrote:
It would be a totally different matter, of course, if you used the
branches I publish via my GitHub repository, added fixup! and squash!
commits, published the result to a public repository and then told me to
pull f
Hi Johannes,
On Fri, Aug 5, 2016 at 1:20 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Thu, 4 Aug 2016, Stefan Beller wrote:
>
>> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
>> wrote:
>> >
>> >> If we were to change our workflows drastically, I'd propose to go a
>> >> way[1] similar
Hi Junio,
On Thu, 4 Aug 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > Like you, I have occasionally been bitten by Junio doing a fixup, and
> > then I end up re-rolling, and lose that fixup.
>
> ... which usually is caught when I receive the reroll, as I try to apply
> to the same base
Hi Richard,
On Fri, 5 Aug 2016, Richard Ipsum wrote:
> On Thu, Aug 04, 2016 at 09:42:18AM -0700, Stefan Beller wrote:
> > On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> > wrote:
> > >
> > >> If we were to change our workflows drastically, I'd propose to go a
> > >> way[1] similar to noted
Hi Duy,
On Fri, 5 Aug 2016, Duy Nguyen wrote:
> On the topic of fixup and squash and everything. Is anyone else
> annoyed that the commit title is taken for fixup!, squash!
> instructions?
I do not know about others, but I am not annoyed by those commit titles. I
think they make tons of sense.
On Wed, Aug 3, 2016 at 6:07 PM, Johannes Schindelin
wrote:
> It would be a totally different matter, of course, if you used the
> branches I publish via my GitHub repository, added fixup! and squash!
> commits, published the result to a public repository and then told me to
> pull from there, that
On Thu, Aug 04, 2016 at 09:42:18AM -0700, Stefan Beller wrote:
> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> wrote:
> >
> >> If we were to change our workflows drastically, I'd propose to
> >> go a way[1] similar to notedb in Gerrit, or git-series,
> >
> > Gerrit is a huge, non-distribut
Johannes Schindelin wrote:
Agreed on all above points :>
> On Thu, 4 Aug 2016, Eric Wong wrote:
> > Of course, centralized systems are unacceptable to me;
> > and with that I'll never claim any network service I run
> > will be reliable :)
>
> Hehehe. I guess that's why the public-inbox is back
Hi Eric,
On Thu, 4 Aug 2016, Eric Wong wrote:
> Stefan Beller wrote:
> > On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> > wrote:
> > > I guess I have no really good idea yet, either, how to retain the ease of
> > > access of sending mails to the list, yet somehow keep a strong tie with
>
Hi Stefan,
On Thu, 4 Aug 2016, Stefan Beller wrote:
> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> wrote:
> >
> >> If we were to change our workflows drastically, I'd propose to go a
> >> way[1] similar to notedb in Gerrit, or git-series,
> >
> > Gerrit is a huge, non-distributed system
On Thu, Aug 04, 2016 at 02:12:22PM -0700, Junio C Hamano wrote:
> > 2. Minor fixups noticed by maintainer, fixed while applying.
>
> This includes different kinds of things:
>
> a) Trivially correct fixes given in other people's review.
>
> b) Minor fixups by the maintainer, to code.
Jeff King writes:
> Like you, I have occasionally been bitten by Junio doing a fixup, and
> then I end up re-rolling, and lose that fixup.
... which usually is caught when I receive the reroll, as I try to
apply to the same base and compare the result with the previous
round.
> But I think such
Stefan Beller wrote:
> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> wrote:
> > I guess I have no really good idea yet, either, how to retain the ease of
> > access of sending mails to the list, yet somehow keep a strong tie with
> > the original data stored in Git.
>
> Does it have to b
On Thu, Aug 04, 2016 at 05:29:52PM +0200, Johannes Schindelin wrote:
> So my idea was to introduce a new --reword= option to `git commit`
> that would commit an empty patch and let the user edit the commit message,
> later replacing the original one with the new one. This is not *quite* as
> nice
On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
wrote:
>
>> If we were to change our workflows drastically, I'd propose to
>> go a way[1] similar to notedb in Gerrit, or git-series,
>
> Gerrit is a huge, non-distributed system. Complex, too. If we change the
> patch submission process, we shou
Hi Stefan,
On Wed, 3 Aug 2016, Stefan Beller wrote:
> On Wed, Aug 3, 2016 at 9:07 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 3 Aug 2016, Junio C Hamano wrote:
> >
> >> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
> >> wrote:
> >> >
> >> > I disagree, however, with the suggestion to
Hi Peff,
On Wed, 3 Aug 2016, Jeff King wrote:
> On Wed, Aug 03, 2016 at 09:53:18AM -0700, Junio C Hamano wrote:
>
> > > Leaving aside Dscho's questions of whether pulling patches from email is
> > > convenient for most submitters (it certainly is for me, but I recognize
> > > that it is not for
On Wed, Aug 3, 2016 at 9:07 AM, Johannes Schindelin
wrote:
> Hi Junio,
>
> On Wed, 3 Aug 2016, Junio C Hamano wrote:
>
>> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
>> wrote:
>> >
>> > I disagree, however, with the suggestion to sift through your `pu` branch
>> > and to somehow replace l
Jeff King writes:
> On Wed, Aug 03, 2016 at 08:33:12AM -0700, Junio C Hamano wrote:
>
>> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
>> wrote:
>> >
>> > I disagree, however, with the suggestion to sift through your `pu` branch
>> > and to somehow replace local branches with the commits f
On Wed, Aug 03, 2016 at 09:53:18AM -0700, Junio C Hamano wrote:
> > Leaving aside Dscho's questions of whether pulling patches from email is
> > convenient for most submitters (it certainly is for me, but I recognize
> > that it is not for many), I would much rather see incremental fixup
> > patch
On Wed, Aug 03, 2016 at 08:33:12AM -0700, Junio C Hamano wrote:
> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
> wrote:
> >
> > I disagree, however, with the suggestion to sift through your `pu` branch
> > and to somehow replace local branches with the commits found there.
>
> To be more
Hi Junio,
On Wed, 3 Aug 2016, Junio C Hamano wrote:
> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
> wrote:
> >
> > I disagree, however, with the suggestion to sift through your `pu` branch
> > and to somehow replace local branches with the commits found there.
>
> To be more in line wit
On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
wrote:
>
> I disagree, however, with the suggestion to sift through your `pu` branch
> and to somehow replace local branches with the commits found there.
To be more in line with the "e-mailed patch" workflow, I think what I should
do is to send
Hi Junio,
On Tue, 2 Aug 2016, Junio C Hamano wrote:
> So either I should change my workflow and mention any and all
> typofixes in my review comments (which consumes the review
> bandwidth), or I should force patch authors to do the "fetch from
> 'pu' and replace" somehow to avoid this kind of ba
Johannes Schindelin writes:
> I tend to think that the underscore is correct: this change is not so much
> about the builtin (which is written with a dash) but about the function
> (written with an underscore, used by more than just merge-recursive, e.g.
> cherry-pick).
Yes, I agree. "merge-rec
Johannes Schindelin writes:
>> > There are a couple of places where return values never indicated errors
>> > before, as wie simply died instead of returning.
>>
>> s/wie/we/;
>
> Right. What can I say, I am surrounded by too many Germans.
>
> I fixed this locally, in case another re-roll should
Hi Junio,
On Mon, 1 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Subject: Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors
>
> s/merge_/merge-/; for this one alone.
I see that de8946de1694a8cf311daab7b2c416d76cb04d23 still shows it
Johannes Schindelin writes:
> Subject: Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors
s/merge_/merge-/; for this one alone.
> There are a couple of places where return values never indicated errors
> before, as wie simply died instead of returning.
s/wie/w
There are a couple of places where return values never indicated errors
before, as wie simply died instead of returning.
But now negative return values mean that there was an error and we have to
abort the operation. Let's do exactly that.
Signed-off-by: Johannes Schindelin
---
merge-recursive.
75 matches
Mail list logo
