lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: improving our workflow with better tools - let's test things.


From: Carl Sorensen
Subject: Re: improving our workflow with better tools - let's test things.
Date: Mon, 21 Oct 2013 12:30:38 +0000
User-agent: Microsoft-MacOutlook/14.3.8.130913

On 10/21/13 1:09 AM, "Werner LEMBERG" <address@hidden> wrote:

>
>>> As far as I can see, github's ticketing system doesn't allow to
>>> simply update the patch; instead, you have to open a new ticket.
>> 
>> Not true at all.  Rebase your branch, then,
>> 
>>     git push -f origin my-branch
>> 
>> ... will overwrite the contents of the pull request branch, and so
>> update the request itself.  I've done it many times. :-)
>
>Good to know, thanks.  [I assume that `overwrite' still somehow
>retains the previously version for reference, right?]
Yes.

The merge request is a merge request for a branch, not for a commit.  So
once you have a merge request up, it tracks any changes in that branch.
This has both positive and negative implications in my mind.  It's
positive in that any work I do on the branch is automatically translated
into the merge request.  It's negative in that any unintended changes I
make on the branch automatically get translated into the merge request.

In our current workflow, once I submit a patch, it's a fixed submission.
I have to resubmit a different patch in order to change it.

In the gitlab workflow, when I submit a merge request, it's a dynamic
thing.  Any time I push my merge-request branch to origin, I'm changing
the merge request.  (Oh -- I just saw the protection against unintended
changes -- don't push the branch to origin!)

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]