How to revert dirty packages

General Usage
1

My Pkg.status() is:

julia> Pkg.status()
1 required packages:
 - Atom                          0.5.9+             master
45 additional packages:
 - ASTInterpreter                0.0.4+             master
 :
 - HttpCommon                    0.2.6
 - HttpParser                    0.2.0+             master (dirty)
 - HttpServer                    0.1.7
 - JSON                          0.8.3
 - JuliaParser                   0.7.4+             master
 - Juno                          0.2.6              master (dirty)
 - LNR                           0.0.2+             master

I put in a couple of debug print statements & two repos are now dirty.

Problem is that Pkg.update() now avoids updating them.

How can I fix this? I don’t wish to preserve my changes?

I’ve been offered instructions such as git reset --hard head but nothing is shifting it.

(I’m on OSX)

2
  1. In the long run you need to learn git.
  2. dirty means, the package manager detects a difference to the assumed checkout/commit → one or more modified files (git status should tell you).
  3. revisiting 1)
    Git - Undoing Things
    your case is: Unmodifying a Modified File
1 Like
3

You could try removing and then re-installing the dirty package:

Pkg.rm("...")
Pkg.add("...")
4

I think you’re supposed to create branches more often. Presumably because it’s it easier to switch between branches than move forward and backward through commits. Of course this isn’t helpful now…

A lot of people may find Git easy. but I’m not one of them. By far the hardest aspect of contributing to Julia is the Git(Hub) side of things, in my experience.

5
  1. Open up GitKraken
  2. Open up the repo
  3. Double click on the remote master branch. It’s the master with the Github local next to it. It will ask if you want to overwrite your local master. Click yes.
  4. Go back to 2. Do for all repos.

I don’t know of an easier way to git than to use GitKraken. If I had to use the command line, I would do this by cd’ing into the repos and just doing git stash. It’s not the same (it saves the changes to the stash), but it’s not very different.

6

@cormullion I was in your same situation, and this tutorial helped me out: Setting up a repository | Atlassian Git Tutorial.
I came to realize that for minor contributions, git is not painfully complicated. You may also find GitHub Desktop a useful tool.

7

Thanks! Although, I’ve seen quite a few videos and read through a few ebooks. The problem for me is not basic Git, but how to match up the development models in the example documents with the actual working development model used in Julia.

For example, I can probably understand this. But seeing the connections and differences with the Julia/GitHub model is the challenge.

8

AFAIK, the Julia development is far, far simpler than that post. All core development happens on the master branch, which is periodically split off into releases branches for old releases and those branches are quasi-dead since they’re only updated for bug fixes.

Individual contributors with commit access create branches on GitHub when they want to show people their code, but those branches are just individuals’ development work and could easily live in forked repos if people were willing to put up with more tedium. People without commit access have to use forks and then provide PR’s because they, by definition, can’t change the main repo’s state without a PR.

Unless I’m missing something, that’s all there is to it. Even Google seems to use a similarly simple approach: [1702.01715] Software Engineering at Google

In case that description is too complicated, here’s an even simpler version:

  • The official living codebase is master. To get new code into master, you have to submit a PR and get it reviewed.

  • The quasi-dead codebase for historical releases is on a set of release branches. Almost no contributors should ever be changing code on release branches and their existence is effectively irrelevant to normal people.

  • Individuals’ work happens on any other branch that’s not master or a release branch. You use a separate branch because you want to be free to do anything you want without review.

4 Likes
9

@johnmyleswhite 's description is dead-on.

Because @johnmyleswhite 's description is dead-on, I would advise against this. I used it for awhile, but it doesn’t handle multiple remotes well. Most likely, you will need two remotes, since one remote will be to the branch you are working on (on your fork), and the other will be the master branch in the original repo. Github Desktop doesn’t handle this well, so I had troubles when using it and it was easier to just use the CLI.

Other GUIs, (like what I recommended, GitKraken) can handle multiple remotes. If you don’t care about being hardcore and would prefer to just drag your branch over “master” and have it open a PR, it’s very nice.

1 Like
10

If i read here about the benefits of single stream development i still wonder why we allow us the luxury of independent package repositories? We could in the first step limit to 1 repo per organisation.

11

From Google’s report:

As of January 2015, this 86 terabyte repository contained a billion files

Many packages will be used as small embedded codes. I get a lot questions pertaining how to use specific parts of the ODE solvers, which is why DifferentialEquations.jl split apart so that way you could have a “low-dependency mode”. Since you download the full repository in Julia, throwing these huge repos at the user is just not user-friendly.

Besides, it goes against encapsulation of toolkits. Google gets to be different because they deploy everything to their giant webservers. We give it to individual user’s computers. If someone wants a small utility library for handling X, why do they need the entirety of JuliaDiffEq/JuliaOpt/JuliaStats just because that’s the org that made it? For a huge webserver, it has to be there anyways, so why not. But we’re developing for a different regime.

12

maybe that’s already not user friendly (yes, i know Pkg3 will be here in a second…).

1 Like
13

It would be nice if there were a Pkg.reset("Foo") function or similar that did the equivalent of git reset --hard. (Would be easy to implement since libgit2 supports this functionality.)

Often, when I’m testing a package out on some test machine, I make experimental changes to a package to help debug problems. However, I don’t have git installed on that machine, and it is a pain to have to download git just to reset the package directory to a clean state.

8 Likes
14

It’s an old topic, but still comes at top of goole search
This is a tip for reverting dirty package for vscode users.

  1. Open dirty package directory from command pallet - press F1 and Julia Open Package Dir...
    image

  2. Discard all Changes from the sidebar
    image