GitHub command line access question #567
Replies: 9 comments 21 replies
-
|
You need to fork the repository, set the origin remote (this should be brian-math/audiveris) to your fork, then push to your fork. You'll then be able to open a pull request to the upstream (audiveris/audiveris) repo. |
Beta Was this translation helpful? Give feedback.
-
|
https://twitter.com/TonyJHerbert22/status/1511824744940720138 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @Marr11317 ! That did the trick :-) |
Beta Was this translation helpful? Give feedback.
-
|
[I have moved this conversation out of #33 since it has nothing to do with drum notation.] @Jojo-Schmitz wrote
After backing up locally the files I changed on my branch, and viewing some log information about my current git branch status, I followed your instructions (making sure I was currently on my drum-notation branch locally): But nothing much seemed to change. Here are the first few lines of output of BEFORE: AFTER: The only thing that has changed is the new pointer upstream/development on the 3rd snapshot. Moreover it seems that drum-notation is a sub-branch of development (at least locally) because its snapshot e65885b occurs above (more recently on the timeline, and a direct successor of) the most recent snapshot in development, 1e34322. However on my personal GitHub account, on the audiveris fork, my drum-notation branch still appears to be a sub-branch of the master branch: when I select my drum-notation branch on the GitHub website, immediately below appears the message: "This branch is 68 commits ahead, 6 commits behind Audiveris/audiveris:master." Clicking the Fetch Upstream button produces the message: "This branch is 6 commits behind the upstream and has conflicts that must be resolved." And if I start the process of issuing a Pull Request, GitHub defaults to asking to merge with the master branch, not the development branch. So something is still wrong on my github.com fork. Suggestions? |
Beta Was this translation helpful? Give feedback.
-
|
@hbitteur / Hervé: Since nobody has responded to my query from Apr 15 (above), I have tried many things this weekend to try to get GitHub to recognize a drum-notation branch as "This branch is up to date with Audiveris/audiveris:development" rather than "This branch is 66 [or 68] commits ahead, 6 commits behind Audiveris/audiveris:master." Most recently I deleted the old drum-notation branches both on my brian-math GitHub fork of the Audiveris project, and on my local computer, and re-created a brand new drum-notation branch while the local development branch was active. In some sense this seems to have been successful: However, on my brian-math/audiveris project on github.com, selecting the new drum-notation branch still displays the same old message, "This branch is 66 commits ahead, 6 commits behind Audiveris/audiveris:master." When I think about it, though, the latter message does perfectly describe where the development branch is, so it is a true and accurate description of where the drum-notation branch is, too. Maybe if I re-submit a PR from the new drum-notation branch (which currently has no changes to any files) to Audiveris/audiveris:development, and if you accept the PR with that destination, that might be enough to force GitHub to state that the drum-notation branch is "up to date with Audiveris/audiveris:development" as we would like. I don't think there is much to lose, since as I mentioned I have rolled back all the code changes that I made on the original drum-notation branch (saved as backup files in a separate directory on my local machine, as you suggested). The only other strategy I can think of is for you to create a new subbranch (maybe call it something different, like "drum-scores") of the development branch on the Audiveris GitHub account, which I could then checkout to my local machine and push to my brian-math fork on github.com. Perhaps such an "official" subbranch would be described by GitHub as "This branch is up to date with Audiveris/audiveris:development", as we want. Please let me know what you would like me to do... [Edit: Well, it looks like I can't issue a PR from the brand new drum-notation to Audiveris/audiveris:development. If I try, GitHub says "There isn’t anything to compare. Audiveris:development and brian-math:drum-notation are identical." So I guess if you want me to issue a PR from the new branch, I'll have to change at least one file. But I could do so in a very innocuous way, e.g. by adding a blank comment at the beginning.] [Edit#2: I think the 2nd strategy might be better: create a new "official" subbranch off of development in the Audiveris GitHub account for adding capabilities involving percussion notation. That way you can pull changes to the subbranch and keep them there for a while, and only merge them with the development branch when you think enough features have been added and they've been fully tested. Feel free to name the new subbranch drum-notation if you like. I'm happy to delete my existing drum-notation branch and start over with yours.] |
Beta Was this translation helpful? Give feedback.
-
|
I'm away from home. I plan to address this when I return on Wednesday.
Le dim. 17 avr. 2022 à 22:13, brian-math ***@***.***> a
écrit :
… @hbitteur <https://github.com/hbitteur> / Hervé:
Since nobody has responded to my query from Apr 15 (above), I have tried
many things this weekend to try to get GitHub to recognize a drum-notation
branch as "This branch is up to date with Audiveris/audiveris:development"
rather than "This branch is 66 [or 68] commits ahead, 6 commits behind
Audiveris/audiveris:master." Most recently I deleted the old drum-notation
branches both on my brian-math GitHub fork of the Audiveris project, and on
my local computer, and re-created a brand new drum-notation branch while
the local development branch was active.
In some sense this seems to have been successful:
% git log --oneline --decorate --graph --all
* 1e34322
<1e34322>
(HEAD -> drum-notation, upstream/development, origin/drum-notation,
origin/development, development) Use of closeable within ProxyMusic
* 40492b9
<40492b9>
Cross-head shape added to the shapes not crossable by curves
...
Notice that the *local* *drum-notation* and *development*, the *upstream*
(Audiveris GitHub account) *development*, and the *origin*
(brian-math/audiveris fork) *drum-notation* and *development* branches
all point to the same commit, namely the latest one made on the development
branch. I believe this is the correct and expected behavior.
However, on my brian-math/audiveris project on github.com, selecting the
new drum-notation branch still displays the same old message, "This branch
is 66 commits ahead, 6 commits behind Audiveris/audiveris:master." When I
think about it, though, the latter message does perfectly describe where
the development branch is, so it is a true and accurate description of
where the drum-notation branch is, too.
Maybe if I re-submit a PR from the new drum-notation branch (which
currently has no changes to any files) to Audiveris/audiveris:development,
and if you accept the PR with that destination, that might be enough to
force GitHub to state that the drum-notation branch is "up to date with
Audiveris/audiveris:development" as we would like. I don't think there is
much to lose, since as I mentioned I have rolled back all the code changes
that I made on the original drum-notation branch (saved as backup files in
a separate directory on my local machine, as you suggested).
The only other strategy I can think of is for you to create a new
subbranch (maybe call it something different, like "drum-scores") of the
development branch on the Audiveris GitHub account, which I could then
checkout to my local machine and push to my brian-math fork on github.com.
Perhaps such an "official" subbranch would be described by GitHub as "This
branch is up to date with Audiveris/audiveris:development", as we want.
Please let me know what you would like me to do...
—
Reply to this email directly, view it on GitHub
<#567 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFIIGAQ2BHW2EQFN5GIQRX3VFRWFLANCNFSM5TBB7LKA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@brian-math It looks like I'm late to the party. I'd be happy to help you with Audiveris and Github. I hope you have a local copy of your work because it has been recently deleted from your remote branch! I suggest to start with a clean local copy: That last command switches your local repository to After that, you'd need to rebase your work onto the freshly cloned If the above suggested After rebasing and testing everything, you can proceed with pushing your new local branch to a remote repository of YOURS. Github won't allow you to push changes directly to the remote repository of the Audiveris project. Doing so isn't safe. Github provides you with the ability to submit pull requests instead. This way, Audiveris developers can integrate your work safely by using Github tools that ensure that nothing gets inadvertently broken. You'll probably need Finally, you can navigate to your Github repository with your browser and open a pull request there, preferably from P.S.: you can move your work to a new branch instead of |
Beta Was this translation helpful? Give feedback.
-
|
@maximumspatium Thank you very much for your reply and detailed suggestions—I appreciate them. In an early email to me, Hervé wrote: • Please have a look at our Git Workflow wiki article: I'd suggest we create a "drum-notation" branch off of "development" branch for this activity. So my assumption was that Hervé wanted to have a rather long-lasting (and public?) branch specifically for developing percussion notation capabilities. I was not expecting to continually merge my "drum-notation" branch into my (local and github.com) copy of the "development" branch, and then issue PR's from there to the Audiveris github.com "development" branch. Rather, I thought the "drum-notation" branch would maintain a separate presence, at least on my brian-math github.com account. [I just noticed your edit: "P.S...", and that is exactly the work-flow I was envisioning. BTW, the first command under your P.S. should be I shall wait and see what @hbitteur says, once he returns home tomorrow, about whether "drum-notation" should be a branch off "development" on Audiveris/audiveris or only on brian-math/audiveris. |
Beta Was this translation helpful? Give feedback.
-
Yes, it should be
It really doesn't matter whether it's going to be a separate branch or not. The key part is to have your work hosted in a remote repository we can pull code from. |
Beta Was this translation helpful? Give feedback.
-
|
I followed your instructions and I now have again a drum-notation branch on my brian-math/audiveris GitHub account. GitHub still describes it as "This branch is 67 commits ahead, 6 commits behind Audiveris/audiveris:master." Maybe that's just the way GitHub works (recall that Audiveris/development "is 66 commits ahead, 6 commits behind master", and I made 1 additional commit to drum-notation). Shall I go ahead and issue a pull request to audiveris:development and see what happens? For the record, here are the local commands I issued, along with the output from a few of them. I can provide the output for every command if that would be helpful. At this point I copied several modified .java files to the appropriate subdirectories in audiveris-new Next I tried |
Beta Was this translation helpful? Give feedback.
-
|
By the way, if you go to the first commit page for drum-notation, brian-math@8d0f4d2, you see that this commit has 1 parent, 1e34322, which happens to be the last commit of the development branch. I think this proves that drum-notation is a sub-branch of development, as desired. |
Beta Was this translation helpful? Give feedback.
-
Your assumption is true. I had and still have the feeling that a full support of drum notation will not be done in a snap and thus requires a public long-lasting specific branch off of our development branch. The problem is that this topic is turning into a discussion about git commands I'm far from mastering. I can help you on Audiveris architecture and code, much less on git subtleties. Here is my proposal:
Any advice on this? Until I push back everything to GitHub, there is no risk. if needed I can just discard my local directory. Update: I initially wrote |
Beta Was this translation helpful? Give feedback.
-
|
Bad news. I tried the proposed actions, and after the This is not a disaster, but I would have preferred some local code inspection and testing before this actual merge. Can someone (Maxim?) give a hand on this? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
It seems that in a |
Beta Was this translation helpful? Give feedback.
-
|
@hbitteur I prefer to use Git commands that perform only ONE action just like the famous Unix philosophy: do one thing and do it well. I usually break down some complex Git action into several simple actions and use the appropriate Git commands. This way, I can greatly minimize the risk of doing something wrong. Plus, each and every Git action can be easily rolled back using a couple of simple commands. |
Beta Was this translation helpful? Give feedback.
-
|
@maximumspatium : I set my local branch drum-notation to track 'upstream drum-scores', but pushed to 'origin drum-notation' (where upstream = https://github.com/Audiveris/audiveris.git and origin = https://github.com/brian-math/audiveris.git). I hope this is correct--it seemed the right way to proceed in case other developers also make modifications to the drum-scores branch. If there is a way to always pull from upstream and push to origin, without having to specify 'origin' as part of the git push command, that would be handy. I did get a rather surprising message after the various git fetch and git merge commands: I don't know why my drum-notation would be 2 commits ahead of drum-scores, since you just pushed my changes from yesterday to the new drum-scores branch. I hadn't made any new commits since then before I issued the above commands. |
Beta Was this translation helpful? Give feedback.
-
|
I suggest to synchronize with the upstream's The 3rd command will first pull changes from the remote branch, then apply your local changes on top of them i.e. rebasing your local branch. In the most cases, it should work out of the box but sometimes you may need to resolve conflicts manually. |
Beta Was this translation helpful? Give feedback.
-
|
Could someone please remind me how to get my personal GitHub development branch to match my local one, after rebasing my local branch onto the end of the fetched Audiveris Github development branch? (Note: origin = github.com/brian-math/audiveris.git, upstream = github.com/Audiveris/audiveris.git) After the fetch from upstream/development, I had locally: Then I did This is how I wanted my local development branch to look! Now I would like to make origin/development look the same. I believe I am asking how to remove the commit 01a8 from origin/development (which after all is identical to 6fa6); i.e. roll origin/development back to ee68. Then presumably I can just Thanks in advance! |
Beta Was this translation helpful? Give feedback.
-
|
Short answer: I have no idea how to do this. I expected Git gurus could give a hand. Here is what came to my mind: This may not be exactly what you are asking for, but at least we could both move ahead from this point. |
Beta Was this translation helpful? Give feedback.
-
I'm trying to push a new local git branch "drum-notation" to GitHub Audiveris project from Mac Terminal, but getting an error:
% git push -u origin drum-notation
[I enter my GitHub username and personal-access-token when prompted]
remote: Permission to Audiveris/audiveris.git denied to brian-math.
fatal: unable to access 'https://github.com/Audiveris/audiveris.git/': The requested URL returned error: 403
% git remote -v
origin https://github.com/Audiveris/audiveris.git (fetch)
origin https://github.com/Audiveris/audiveris.git (push)
I deleted the github.com entry in Mac Keychain Access, although when I logged out and back in to github.com, a new keychain entry was created automatically by Safari, but this one is suffixed with "(Passwords not saved)" and does not contain either my GitHub username or password.
Suggestions? @maximumspatium ?
Beta Was this translation helpful? Give feedback.
All reactions