Can I have imagej-ops repo privileges (at least temporarily)?

@ctrueden / @dietzc , Could I have write permissions to the imagej-ops repo on GitHub (at least temporarily). I have some work on the featuresets branch that I’d like to provide via pull request. Long story short, I should have forked the repo to do so but I didn’t. I at least did the work on a new branch “featuresets_JW” and wanted to submit a pull request to merge it with “featuresets” but can’t seem to do so without permissions. Maybe you have another easy workaround. If possible though, it would save me a bunch of time redoing edits, comments, and commits.



Why do you want to merge changes into an obsolete branch? I’m rather tempted to delete the branch completely, as we moved the development of FeatureSets temporarily into KNIME. We want to merge back these changes to Ops on the next hackathon.



Jay, there is no reason you “should have done so”. Just fork it now, push your branch to the new fork, and then create a PR. Unless you don’t want to merge it any more after what @dietzc just said :wink:

1 Like

Maybe I should elaborate a bit on why I decided to move the stuff into KNIME Image Processing instead of imagej-ops for now: Simply lack of time. I won’t come up with a nice solution/framework/implementation without hacking on the imagej-ops core. I would love to see the stuff in ops and I hope on the next hackathon (January '16 ) I can do this together with @ctrueden. That’s basically it. Sorry, that I can’t share this code earlier. However, all main components, like CachedOpEnvironment or all the features themselves are part of ImageJ-Ops already.

I agree with @ehrenfeu. There is no permission required to submit a PR. That is the entire point of the fork-and-PR model: anyone can do it.

@jaywarrick You are doing a lot of great work, and I praise your enthusiasm, but I have reservations about granting repository write permissions to anyone who is still struggling with the concepts of Git remote repositories, forks, branches, etc. I would rather you be fully comfortable with these concepts before you start pushing directly to the official remotes. The catch-22 is: once you are fully comfortable, you won’t need to push directly because you’ll be able to easily submit PRs from your fork.

Some advice about your specific troubles above:

You should have two remotes linked to your clone; e.g.:

$ git remote -v
jaywarrick	git:// (fetch)
jaywarrick (push)
origin	git:// (fetch)
origin (push)

If you are missing a remote, add it; e.g.:

$ git remote add jaywarrick

Make sure your master branch tracks origin/master, not jaywarrick/master:

$ git branch -vv
* master               09d213a [origin/master] Merge pull request #267 from imagej/lbp-format

If it doesn’t track the right remote, change it:

$ git checkout master
$ git branch --set-upstream-to origin/master

If your branch gets messed up and out of sync, you can hard reset it back to the upstream:

$ git checkout master
$ git reset --hard origin/master
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

This will lose local changes though, so be careful.

More tips on the Git Notes page.

Once your master branch is synced to upstream, then your fork’s master branch becomes irrelevant. You do not need to keep it in sync—you can just let it molder. When you create a topic branch by branching from master, you’ll be branching from the latest upstream work:

$ git checkout master
$ git pull
$ git checkout -b shiny-new-branch

Do your work, make commits, etc. Then push it to your fork:

$ git push -u jaywarrick shiny-new-branch

Then visit and you’ll see a notification that you just pushed some changes… and would you like to make a pull request? Click the button and you are good to go.

For anyone besides Jay who bothered to read this far, here is a cookie for you! I personally use this tool to file most of my PRs from the command line:

$ git pull-request

And you get an editor window just like when you are doing a commit… but for your PR! :trophy:


Thank you so much for taking the time to create this sort of reference tutorial. I know I’m benefiting but hopefully others as well. Thanks.

Just to clear up a bit of confusion. Although my most recent PR involved a snafu with my out of date fork, this snafu was with a direct clone of the imagej-imagej-ops repo. I didn’t realize that I could push a branch from a directly cloned repo to a forked repo to get back into the fork-and-PR model of things. I figured there might be a solution like this which is why I asked about other potential easy workarounds.

Your points on setting and changing remotes are very helpful. I’ll try to do so in the future.

As far as submitting a PR for a defunct branch, I understand what you mean. Seems kind of pointless. Further, it is more work on your ends to incorporate the changes. Like you said, at least the fundamental pieces are there to get something working (i.e., a complement of feature sets to use in the near term) for my purposes, which indeed was my primary intention (vs fleshing out a more general feature set infrastructure). I was just looking for an appropriate way to share my work so it occurs in the open where other people might benefit (even if all that happens is that @dietzc might see a small bug I stumble upon and makes the associated change over in the knip repo). If a PR to this defunct branch isn’t the way to share what I’m doing, that’s fine. But working off the imagej-ops repo (vs knip) is certainly the most productive method for me to utilize these feature extraction capabilities at the moment. If you have a better way to share what I’m doing or don’t feel it is worth sharing in this situation, I’m completely open to suggestions and will wait for your feedback before submitting a PR.


@jaywarrick this is a very special situation at the moment (and I don’t like the fact that FeaturSets are living in KNIP). But I really can’t find the time until the hackathon to get my work into imagej-ops. Sorry that you have to wait. However, knip is also open-source, so feel free to grab any code you need. In January we hopefully have one unified solution everyone can use, work on and contribute to.

again, sorry for the trouble.