Re: First-time pushing a patch

[David Kastrup]

Peekay Ex <address@hidden> writes:

> David,
>
> On Wed, Nov 9, 2011 at 8:58 AM, David Kastrup <address@hidden> wrote:
>
> ...
>
>>
>> [Diversion: by the way, Phil and Graham?  I have come to the conclusion
>>  that it is better if Patchy does not attempt any rebases or merges on
>>  its own.  Can you change that accordingly?  It should quite simplify
>>  Patchy and make its behavior more predictable: it would just try to
>>  push its tested version of dev/staging to master, and if that fails,
>>  it fails.
>>
>>  In that way, we are sure that _only_ completely tested versions end up
>>  in master, and with identical structure to how people put them into
>>  dev/staging.
>>
>>  A direct push to master bypassing dev/staging should be an emergency
>>  measure, and then Patchy can well wait until somebody manually rebased
>>  dev/staging.  Maybe we should rename the staging branch into just
>>  "staging" as the "dev/" is needlessly obscure. ]
>>
>
> At the moment (it is I that has been running the compile script) it is
> completely manual.
>
> Once the script has run (and shows no errors) it reports
>
> --snip--
>
> HEAD is now at [commit hash]... [commit summary]
> Current branch origin/dev/staging is up to date.
> push merge:
> (do this manually for debugging/testing)
>        git push origin HEAD:master
>
> --snip-
>
> Then I do the push manually.

But the script presumably does some rebase or other to get at the state
before pushing?

Most likely the message "Current branch origin/dev/staging is up to
date." comes from a rebase command.  It may make sense to throw that
command from the script, or at least let it use the option --ff-only
(somewhat pointlessly since that would just help if dev/staging was
strictly behind master, in which case dev/staging would be made to catch
up).

-- 
David Kastrup