These are chat archives for astropy/astropy

31st
Jan 2017
Brigitta Sipocz
@bsipocz
Jan 31 2017 12:20
Hi @dmopalmer
Sorry, I have only noticed your messages now.
As for the rebase you always need fetch the latest remotes first. Then use astropy/master for the base.
% git fetch --all
% git rebase -i astropy/master
Currently you have 5 commits in your branch coord-offset. The interactive rebase command will bring up an editor, with two commits in it (as the other 3 are merge commits by other people and those are recognized to be in astropy/master already). In this instance you don't need to any edits, leave the two commit. It's OK to have more than one commit in a PR if those are related to the PR.
=====
Brigitta Sipocz
@bsipocz
Jan 31 2017 12:26
I'm afraid you can't restart the travis jobs, only people with write access to the astropy repo can do that. Sometimes we have glitches, the URL issue is one of those, so please ignore it.
=====
If you committed something to a branch, and then pushed it to the remote for github to pick it up, it should usually appear within a minute there. Sometimes if github has an outage it can take longer. You can check github's status here: https://status.github.com/
Feel free to ping us on the PR if you experience these kind of issues.
David Palmer
@dmopalmer
Jan 31 2017 16:49
No luck. Needed a single revision and invalid upstream.
% git remote -v
origin    https://github.com/dmopalmer/astropy.git (fetch)
origin    https://github.com/dmopalmer/astropy.git (push)
upstream    https://github.com/astropy/astropy.git (fetch)
upstream    https://github.com/astropy/astropy.git (push)
% git status
On branch coord_offset
Your branch is up-to-date with 'origin/coord_offset'.
nothing to commit, working tree clean
% git fetch --all
Fetching origin
Fetching upstream
% git rebase -i astropy/master
fatal: Needed a single revision
invalid upstream astropy/master
Brigitta Sipocz
@bsipocz
Jan 31 2017 16:50
OK, I see. Try with this instead:
git rebase -i upstream/master
actually I think this should work out of the box, too:
git rebase upstream/master
David Palmer
@dmopalmer
Jan 31 2017 16:51
% git rebase -i upstream/master
error: could not apply e0fb553... Offsets working.

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply e0fb553e05f19c8231dedbbb2bb8e903d36e54a8... Offsets working.
matrixbot
@matrixbot
Jan 31 2017 16:52
adamginsburg on Freenode hey, anyone here have experience dealing with loading shapely & getting the error "OSError: Could not find lib c or load any of its variants []." ? I'm trying to run astropy-regions tests and getting stuck there
Brigitta Sipocz
@bsipocz
Jan 31 2017 16:52
ok. what does git status say?
There seems to be a conflict, thus the error above
David Palmer
@dmopalmer
Jan 31 2017 16:53
% git status
interactive rebase in progress; onto 2b3bf33
Last command done (1 command done):
   pick e0fb553 Offsets working.
Next commands to do (2 remaining commands):
   pick aba360e Restrict `SkyCoord.offset_by` to merely be `SkyCoord.directional_offset_by(posang,sep)` And give notes on how to do more elaborate offsets.
   pick 662649c Fixing lack of newline on last line.
  (use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'coord_offset' on '2b3bf33'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

    both modified:   astropy/coordinates/angle_utilities.py
    both modified:   astropy/coordinates/sky_coordinate.py
    both modified:   astropy/coordinates/tests/test_sky_coord.py

no changes added to commit (use "git add" and/or "git commit -a")
Brigitta Sipocz
@bsipocz
Jan 31 2017 16:54
ideally you should now edit those three files to resolve the conflicts. Though I'm very much surprised to see that there are conflicts.
So give me 5 mins to try this locally.
David Palmer
@dmopalmer
Jan 31 2017 16:55
I had to pull my other PR because this new code relies on it. So...
Brigitta Sipocz
@bsipocz
Jan 31 2017 16:56
I see. still there shouldn't be a problem or conflict doing so.
which one is the other branch needed for this?
David Palmer
@dmopalmer
Jan 31 2017 16:59
posang_fix (PR #5723)
One common github cycle I get into, trying to squash commits is:
too many commits
rebase --> conflicts
fix conflicts --> commit
rebase continues --> now there is the squashed commit and the conflict-xied commit
too many conflicts: return to start.
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:09
this is a very weird branch. The first commit is a merge of astropy/astropy#5715 that has nothing to do with coordinates. However git blame blames def offset_by() for that.
Based on the long form commit messages it seems that you've squashed unrelated commits into that one, and thus every new rebase fails with various errors.
so this one is indeed a complicated case
David Palmer
@dmopalmer
Jan 31 2017 17:14
I pulled (or maybe fetched or maybe merged) the upstream/master and rebased when I first tried to submit the PR as a WIP. That lead to somehow linking in #5715. But I thought that that particular confusion had been washed away.
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:16
it seems that you've stashed a few commits into that one, and that causes the issues. The easiest would be to start a new branch and cherry-pick the relevant changes, but since basically everything can be solved on a branch, I'll come up with a series of commands that will help you restore order in this branch.
just give a bit more time ;)
David Palmer
@dmopalmer
Jan 31 2017 17:20
xkcd#1597 again.
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:27
The situation is not that bad ;)
so here is the workflow:
git reset HEAD~6
git stash save temp
git rebase upstream/master
git cherry-pick 1dabe88cd14a2eb4486d26b5b29df4213e5a3005
git stash pop
David Palmer
@dmopalmer
Jan 31 2017 17:28
I currently have unresolved conflicts wiht the lines ike
++>>>>>>> e0fb553... Offsets working.
and a rebase in progress.
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:29
obviously this is after you;'ve aborted the current rebase
the first reset should take you back to the bottom of your current branch.
now you have a bunch of files, most of them containtining unrelated changes
second command temporarily saves them
third takes you to the top of master
4th cherry-pick the commit from #5723, so it's distinct and not mixed with new changes
5th brings back the temporarily saved changes.
git recognizes that the unrelated changes are due to other commits on master, so now you only see 3 files changed
and those changes seems to be the ones you've made
Now you can commit these changes together
(this is the messy part, as the history of those changes are lost, if you want to keep that I can come up with something, but I think it is probably ok this way, too)
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:35
so once you've committed, you need to force push back to your remote branch
David Palmer
@dmopalmer
Jan 31 2017 17:35
git commit -a
git push --force
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:36
I tend to prefer stating the branch to push to, especially when force pushing (to limit the chances to overwrite other branches)
David Palmer
@dmopalmer
Jan 31 2017 17:37
% git status
On branch coord_offset
Your branch is up-to-date with 'origin/coord_offset'.
nothing to commit, working tree clean
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:38
yes, it looks good now looking at the PR
David Palmer
@dmopalmer
Jan 31 2017 17:38
It still has 2 commits.
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:38
you've 2 commits. The first is the copy from #5723, and the 2nd is the actual changes, so just as it should be
David Palmer
@dmopalmer
Jan 31 2017 17:40
I thought that the github standard was only single-commit PRs would be accepted.
Brigitta Sipocz
@bsipocz
Jan 31 2017 17:40
We don't have any policy that limits the number of commits in a PR, and it's definitely advantageous to keep commits of other PRs separate, so minimizing future conflicts, etc (git notices identical commits and thus that a PR is built on top of another)
Nope. Some packages have this standard, but even then they usually squash during merging.
Occasionally some of the maintainers of astropy ask for squashing commits, but that usually happens when unrelated big changes are in the history, or when there are many one liner changes in an otherwise trivial PR.
David Palmer
@dmopalmer
Jan 31 2017 17:46
OK. Thank you for the help. On to the next task.