On 13 nov 2011, at 11:39, Walter Bright wrote:

> 
> 
> On 11/12/2011 6:23 AM, Jason House wrote:
>> 
>> I've been wondering if it would be a good idea to set up a workflow where Walter does more than one pull request at a time. After testing all individual pulls, the auto tester could try testing all (passing) pulls from a single author all applied on top of each other. If that larger test passes, then maybe it could save several steps for Walter by handling multiple pull requests at once?
> 
> I've avoided multiple pulls at once, because when they fail it's just miserable.

I you do everything on your local machine it's easy to rewrite history and start all over, if necessary.

git reset --hard <hash>

The above command will rewrite history and remove everything commit made after <hash>. This is a good page describing different ways of undoing commits: http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html

Just for the record, if you do a git reset --hard accidentally that you want to revert, have a look at git reflog.

Regards,
Alex

On Sun, Nov 13, 2011 at 12:37 PM, Jacob Carlborg <doob at me.com> wrote:
>
> On 13 nov 2011, at 11:39, Walter Bright wrote:
>
>>
>>
>> On 11/12/2011 6:23 AM, Jason House wrote:
>>>
>>> I've been wondering if it would be a good idea to set up a workflow where Walter does more than one pull request at a time. After testing all individual pulls, the auto tester could try testing all (passing) pulls from a single author all applied on top of each other. If that larger test passes, then maybe it could save several steps for Walter by handling multiple pull requests at once?
>>
>> I've avoided multiple pulls at once, because when they fail it's just miserable.
>
> I you do everything on your local machine it's easy to rewrite history and start all over, if necessary.
>
> git reset --hard <hash>
>
> The above command will rewrite history and remove everything commit made after <hash>. This is a good page describing different ways of undoing commits: http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On Nov 13, 2011, at 5:39 AM, Walter Bright <walter at digitalmars.com> wrote:

> 
> 
> On 11/12/2011 6:23 AM, Jason House wrote:
>> 
>> I've been wondering if it would be a good idea to set up a workflow where Walter does more than one pull request at a time. After testing all individual pulls, the auto tester could try testing all (passing) pulls from a single author all applied on top of each other. If that larger test passes, then maybe it could save several steps for Walter by handling multiple pull requests at once?
> 
> I've avoided multiple pulls at once, because when they fail it's just miserable.

Step 1 is to make that less miserable :) while there are a git few operations that violate this rule, you can use the following mental model: every commit in git creates an immutable struct that points to its parent nodes. The heads of branches are pointers to these nodes. Regardless of what you've done over the last two hours, your original state is state is still there. All you have to do is reset that pointer and the rest will (eventually) get garbage collected.

Personally, I use gitk a lot for a graphical view, but "git log" works fine too. Once you find the sha1 id, you can pass that to reset --hard.

It is very simple as long as you haven't pushed your changes to the public repository. Once things are in the public repository, others might have a copy and things get more complicated. I think github's pull button updates the public repository? Setting up your own remotes and doing pulls from them will give you extra flexibility.

mrmocool at gmx.de, el 11 de noviembre a las 18:33 me escribiste:
> Am 11.11.2011, 18:18 Uhr, schrieb kenji hara <k.hara.pg at gmail.com>:
> 
> >To Walter
> >
> >I have posted 130 pulls on github in a year, but about forty ones are
> >still opened.
> >I'd like to increase speed of merging, but I don't know the way to
> >realize it.
> >What is the necessary?
> 
> The real necessity is giving commit rights to at least you and Don. Your pull requests are almost always accepted without further comments/complaints.

Usually you don't need to give "commit" rights with git, you just can trust some people and do merge their patches without further testing. Also, trusted people can have branches with other people's patches that they have tested to help Walter not having to do all the review/testing of "untrusted" contributors.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Dentro de 30 a?os Argentina va a ser un gran supermercado con 15
changuitos, porque esa va a ser la cantidad de gente que va a poder
comprar algo.
	-- Sidharta Kiwi

On 13 November 2011 11:39, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 11/12/2011 6:23 AM, Jason House wrote:
>>
>> I've been wondering if it would be a good idea to set up a workflow where Walter does more than one pull request at a time. After testing all individual pulls, the auto tester could try testing all (passing) pulls from a single author all applied on top of each other. If that larger test passes, then maybe it could save several steps for Walter by handling multiple pull requests at once?
>
> I've avoided multiple pulls at once, because when they fail it's just miserable.

I just found this diagram. I think it's very helpful model. Google are obviously pretty good at this stuff.

http://source.android.com/source/life-of-a-patch.html

Looking at that diagram, the only thing Walter _needs_ to be doing is
the Approval 'code looks good' step.
Yet the "Verifier" role is the one which is taking up all the time,
even though it can potentially be almost 100% automated.

Wouldn't it be great if Walter just needed to give a list of pull requests which "look good" to the autotester, and then have them automatically pulled and tested. If it passes, merge into trunk. If not, report failure. Then move to the next one of the list.