Hi John,

Thank you, this is really useful!

I don't understand the purpose of renaming the repository to
galaxy-central-new-feature - what does this achieve?
I'm pretty new to mercurial and more familiar with git, so that could
be why I'm confused.

Thanks,
Clare

On 24 August 2012 00:07, John Chilton <chil...@msi.umn.edu> wrote:
> I don't know that difficult is the right word, I would call the
> process heavy handed and time consuming, especially relative to
> similar git workflows. I have heard the Galaxy developers say on
> multiple occasions the prefer pull requests coming using a dedicated
> clone though and this makes a lot of sense because branches stick
> around forever in mercurial. So I now use dedicated repositories for
> each of my pull requests.
>
> I am still trying to optimize my workflow, but here is a high level
> overview of my current process. We have a local version of Galaxy
> (lets call it msi-galaxy), if we want to push changes back I generally
> create a dedicated clone of galaxy-central on bitbucket for this
> change (say galaxy-central-feature1) and then export the desired
> revision/revisions as a patch from our local branch and import it in
> my feature clone.
>
> % cd msi-galaxy
> % hg export -r rev1 -r rev2 > /tmp/feature1.patch
> % cd ..
> % hg clone ssh://h...@bitbucket.org/jmchilton/galaxy-central-feature1
> % cd galaxy-central-feature1
> % hg import /tmp/feature1.patch
> % hg push
>
> Create pull request.
>
> Other tricks I have learned:
>
> Use ssh keys for bitbucket interactions instead of https, it seems
> considerably faster.
>
> You can add --no-commit to the import and then manually commit. This
> can let you map multiple changesets from your local branch to the
> feature clone (a poor man's rebasing I guess).
>
> The longest part of the process is the original clone down of the
> feature clones. So I have just started reusing old clones for this.
>
> - Rename galaxy-central-old-feature to galaxy-central-new-feature on 
> bitbucket.
> - % cd galaxy-central-old-feature
> - % hg pull ssh://h...@bitbucket.org/galaxy/galaxy-central # catch up
> with galaxy-central
> - Make changes
> - % hg push ssh://h...@bitbucket.org/jmchilton/galaxy-central-new-feature
> - Create pull request.
>
> The downside of this cheat is that previously accept pull requests now
> have source repository names associated with them in bitbucket, like
> this 
> https://bitbucket.org/galaxy/galaxy-central/pull-request/44/allow-usage-of-directory-of-configuration.
>
> -John
>
> ------------------------------------------------
> John Chilton
> Senior Software Developer
> University of Minnesota Supercomputing Institute
> Office: 612-625-0917
> Cell: 612-226-9223
>
>
> On Thu, Aug 23, 2012 at 8:29 AM, Langhorst, Brad <langho...@neb.com> wrote:
>> Maybe I'm just doing it wrong… but I find it unusually difficult to put 
>> together a coherent pull request without doing a dedicated repo clone.
>> maybe somebody who knows a good way to submit pull requests could populate 
>> this wiki page?
>>
>> http://wiki.g2.bx.psu.edu/Develop/Mercurial
>>
>> brad
>> On Aug 23, 2012, at 8:55 AM, Jeremy Goecks <jeremy.goe...@emory.edu>
>>  wrote:
>>
>>> For a simple patch like yours, just pasting and sending your diff to the 
>>> list works well:
>>>
>>> %hg diff
>>> ...
>>>
>>> For bigger patches/enhancements, a bitbucket fork + pull request is highly 
>>> encouraged.
>>>
>>> Best,
>>> J.
>>>
>>> On Aug 23, 2012, at 4:47 AM, James wrote:
>>>
>>>> Hi All,
>>>>
>>>> Today I found a bug relating to the file permissions in composite 
>>>> datatypes. When
>>>> the extrafiles directory was created and the server was running through 
>>>> apache, the permission did not
>>>> allow a galaxy user to download by following the HTML link. Found it was 
>>>> related to meta data files
>>>> not using the os.chmod function to set the permissions of the user data in 
>>>> upload.py. Added that
>>>> line of code and it works and the file permissions match that of other 
>>>> files in the database.
>>>>
>>>> Somehelp with submitting a patch would be welcome ( although one line 
>>>> patch it would be helpful to me.)
>>>>
>>>> Cheers
>>>>    James Boocock
>>>> ___________________________________________________________
>>>> Please keep all replies on the list by using "reply all"
>>>> in your mail client.  To manage your subscriptions to this
>>>> and other Galaxy lists, please use the interface at:
>>>>
>>>> http://lists.bx.psu.edu/
>>>
>>>
>>> ___________________________________________________________
>>> Please keep all replies on the list by using "reply all"
>>> in your mail client.  To manage your subscriptions to this
>>> and other Galaxy lists, please use the interface at:
>>>
>>>  http://lists.bx.psu.edu/
>>
>> --
>> Brad Langhorst
>> langho...@neb.com
>> 978-380-7564
>>
>>
>>
>>
>>
>> ___________________________________________________________
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>>
>>   http://lists.bx.psu.edu/
>
> ___________________________________________________________
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>
>   http://lists.bx.psu.edu/
>
>



-- 

Clare Sloggett
Research Fellow / Bioinformatician
Life Sciences Computation Centre
Victorian Life Sciences Computation Initiative
University of Melbourne, Parkville Campus
187 Grattan Street, Carlton, Melbourne
Victoria 3010, Australia
Ph: 03 903 53357          M: 0414 854 759

___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Reply via email to