Best practice for working on your own branch of a Julia package

[Milktrader]

I'm finding myself making small modifications to existing Julia packages and would like to know what the best practice is for this process.

At first, I was making changes in the git submodule but decided this was a bad idea.

Then I created a branch inside the .julia/my_favorite_julia_package and this worked fairly well, except for when I wanted to do a pull request. For this to work, you need to fork the original project, push your branch to your own fork and then do the pull request. So I did a sensible thing and did $git clone <the fork of my favorite julia package> in a separate directory altogether. This worked fine for the pull request, but how do I *use* this branch?

Of course I tried:

julia> load("~/git/my_favorite_julia_package")

but then I got a fail on using:

julia> using My_favorite_julia_package

in module path: My_favoite_julia_package not defined

Wat? I thought this used to work. 

Same result for two packages (DataFrames, Calendar). and doing require("~/git/my_favorite_julia_package") gives the same result. 

Regards, 

Dan

[Patrick O'Leary]

There's definitely still some rough spots here. A general note:

A single local git repository can have multiple remotes. The original clone (from the repository of record) will, by default, be called "origin" (hence incantations such as "origin/master"). You can add your own with git remote add name url where "name" is what you want to call the remote and "url" is an appropriate URL. So the normal work flow (assuming everything is on GitHub) would be:

1. Fork the remote repository on GitHub.
2. Add your fork as a new remote. I usually name this remote "mine".
3. git checkout origin/master
4. git checkout -b my-new-branch
5. Do new and exciting development on this branch with commits and stuff
   
6. git push mine HEAD
7. Back on GitHub, go to your fork, select the my-new-branch branch, and hit the pull request button.
   

[Tim Holy]

On Thursday, December 20, 2012 10:17:17 AM Milktrader wrote:
> require("~/git/my_favorite_julia_package")

When you clone directly, you probably need the .jl extension.

But the paths don't work out. You can add directories to your .julia that are
not managed by the package manager.

--Tim

[Kevin Squire]

On Thursday, December 20, 2012 10:25:00 AM UTC-8, Patrick O'Leary wrote:

There's definitely still some rough spots here. A general note:

A single local git repository can have multiple remotes. The original clone (from the repository of record) will, by default, be called "origin" (hence incantations such as "origin/master"). You can add your own with git remote add name url where "name" is what you want to call the remote and "url" is an appropriate URL. So the normal work flow (assuming everything is on GitHub) would be:

1. Fork the remote repository on GitHub.
2. Add your fork as a new remote. I usually name this remote "mine".
3. git checkout origin/master
4. git checkout -b my-new-branch
5. Do new and exciting development on this branch with commits and stuff
   
6. git push mine HEAD
7. Back on GitHub, go to your fork, select the my-new-branch branch, and hit the pull request button.
   

From here:

8. Once the patch is accepted, revert to tracking upstream development with  git checkout HEAD^0 

There will be a command for this and some of the other tasks above (Pkg.manage() I think--see https://github.com/JuliaLang/julia/issues/1778, and one other conversation that I can't find).

Kevin

 

[Milktrader]

this is all done inside the .julia directory, yes?

[Kevin Squire]

yes.

[John Myles White]

Yup.

--
 
 
 

[Milktrader]

Alright, I've followed the steps, created a branch called timeseries and successfully pushed to my fork. But now I want to get back to the original package.

✈  git checkout HEAD^0 

Note: checking out 'HEAD^0'.

You are in 'detached HEAD' state. You can look around, make experimental

changes and commit them, and you can discard any commits you make in this

state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at fba23b2... added stubb to show

And now to make sure I'm back on the original, I take a peak at my changes to make sure they're no longer there .

[Calendar ((d026f93...))] 

✈  vi src/Calendar.jl 

But the changes I made to my branch are there, Huh?

I guess I'm still on my fork? How do I get back to the original source?

[Milktrader]

Thinking once you fork you stay on the fork

[Daniel Casimiro]

git checkout HEAD^0

That doesn't change your branch and I think that it only rolls you back one commit. How many commits did you make? I would try checking out the master branch from the original package. I find git a lot easier to grok if I make all of my commits on dedicated branches. Then, you can use master for tracking upstream and rebasing. 

One of the package guys has to chip in now. I'm not sure how to tell the package system to resume tracking. (Pkg.update() ?)

Dan

--
 
 
 

[Milktrader]

I'd like to get out of my sandbox and get back into the official version of the package, but at this point this is becoming more of a git-related question than how-does-julia-do-it question. 

Thanks for the input.

Cheers, 

Dan

[Patrick O'Leary]

HEAD^  is parent of the current location; I'm not sure what that's supposed to do here.

You can get back on track by

git checkout $(cat ~/.julia/METADATA/PackageName/versions/0.0.0/sha1)

...(from memory, hope that's right) with PackageName being the name of the package in question, but I think you then have to fixup something in your global REQUIRE to get tracking restarted. Kind of painful.

[Stefan Karpinski]

I'm in the middle of adding some Pkg features for doing this stuff easier. The goal is that modifying and using a package in-place in your .julia directory should be easy... we're getting there, gradually.

--
 
 
 

[Tim Holy]

On Thursday, December 20, 2012 03:23:37 PM Stefan Karpinski wrote:
> I'm in the middle of adding some Pkg features for doing this stuff easier.

Awesome! Thanks for tackling this, Stefan!

--Tim

[Kevin Squire]

Sorry to mislead here!  Patrick's is the right solution for now.