> Editing text files isn't that hard, we do it all the time.
It is not indeed. But doing it all over again and again is hard and error prone.
I did re-read the man page on git format-patch and found the --notes
option, which I am going to try
to use in my workflow. That way I only need to update
From: "Michael Haggerty"
Sent: Tuesday, November 25, 2014 12:28 AM
On 11/21/2014 07:00 PM, Junio C Hamano wrote:
Michael Haggerty writes:
I don't think that those iterations changed anything substantial
that
overlaps with my version, but TBH it's such a pain in the ass
working
with patches
On 2014-12-03 03.20, Stefan Beller wrote:
> On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> It seems like a few desirable features are being talked about here, and
>>> summarizing the discussion as "centralized" vs "decentralized" is too
>>> simplistic. W
Jonathan Nieder writes:
> I don't think there's any reason that newcomers should need more
> iterations than regulars to finish a patch. Regulars are actually
> held to a higher standard, so they are likely to need more iterations.
>
> A common mistake for newcomers, that I haven't learned yet h
Stefan Beller wrote:
> How are non-regulars/newcomers, who supposingly need more iterations on
> a patch, supposed to handle the inter patch change log conveniently?
I think this is one of the more important issues.
I don't think there's any reason that newcomers should need more
iterations than
On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> It seems like a few desirable features are being talked about here, and
>> summarizing the discussion as "centralized" vs "decentralized" is too
>> simplistic. What is really important?
>>
>> 1. Convenient and
Michael Haggerty writes:
> It seems like a few desirable features are being talked about here, and
> summarizing the discussion as "centralized" vs "decentralized" is too
> simplistic. What is really important?
>
> 1. Convenient and efficient, including for newcomers
> 2. Usable while offline
> 3
> A bot could subscribe to the list and create branches in a public repo.
> (This idea feels familiar -- didn't somebody attempt this already?)
Thomas Rast maintains git notes that link git commits to their gmane
discussion, you can get them with
[remote "mailnotes"]
url = git://github.com/tras
On Fri, Nov 28, 2014 at 04:34:09PM +0100, Michael Haggerty wrote:
> My ideal would be to invert the procedure. Let the patches in a public
> Git repository somewhere be the primary artifact, and let the review
> process be focused there. Let email be an alternative interface to the
> central review
On 14-11-28 09:31 AM, Michael Haggerty wrote:
> On 11/27/2014 06:46 PM, Torsten Bögershausen wrote:
>> On 2014-11-25 01.28, Michael Haggerty wrote:
>> []
>>> Let me list the aspects of our mailing list workflow that I find
>>> cumbersome as a contributor and reviewer:
>>>
>>> * Submitting patches t
On 11/27/2014 11:53 PM, Eric Wong wrote:
> Torsten Bögershausen wrote:
>> On 2014-11-25 01.28, Michael Haggerty wrote:
>>> [...]
>> In short:
>> We can ask every contributor, if the patch send to the mailing list
>> is available on a public Git-repo, and what the branch name is,
>> like _V2.. Does
On 11/27/2014 06:46 PM, Torsten Bögershausen wrote:
> On 2014-11-25 01.28, Michael Haggerty wrote:
> []
>> Let me list the aspects of our mailing list workflow that I find
>> cumbersome as a contributor and reviewer:
>>
>> * Submitting patches to the mailing list is an ordeal of configuring
>> form
From: "Matthieu Moy"
Torsten Bögershausen writes:
On 2014-11-25 01.28, Michael Haggerty wrote:
[]
Let me list the aspects of our mailing list workflow that I find
cumbersome as a contributor and reviewer:
* Submitting patches to the mailing list is an ordeal of configuring
format-patch and
Torsten Bögershausen wrote:
> On 2014-11-25 01.28, Michael Haggerty wrote:
> > * Or I save the emails to a temporary directory (awkward because, Oh
> > Horror, I use Thunderbird and not mutt as email client), hope that I've
> > guessed the right place to apply them, run "git am", and later try t
Torsten Bögershausen writes:
> On 2014-11-25 01.28, Michael Haggerty wrote:
> []
>> Let me list the aspects of our mailing list workflow that I find
>> cumbersome as a contributor and reviewer:
>>
>> * Submitting patches to the mailing list is an ordeal of configuring
>> format-patch and send-em
On 2014-11-25 01.28, Michael Haggerty wrote:
[]
> Let me list the aspects of our mailing list workflow that I find
> cumbersome as a contributor and reviewer:
>
> * Submitting patches to the mailing list is an ordeal of configuring
> format-patch and send-email and getting everything just right, u
On 11/21/2014 07:00 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I don't think that those iterations changed anything substantial that
>> overlaps with my version, but TBH it's such a pain in the ass working
>> with patches in email that I don't think I'll go to the effort of
>> chec
17 matches
Mail list logo
