Midilist and -1
-
@d-healey Yeah so it is how I understand it (of course pull requests don't necessarily have to be for one commit)
Effectively, once the merge is done the branches can be deleted. And that's a good thing because I don't want to deal with 60 branches... -
@ustk Yeah. I only found out about it recently and reformatted my massive pull request into lots of little ones. It made it easier for Christoph to check them all too and merge them.
-
@d-healey I wanted to say I'll do it this way from now, but it's even better if I can reformat this last pull request. Never done that though so let me check ;)
-
@ustk Start making branches and cherry-pick the commits from your develop branch, then delete your current pull request.
-
@d-healey said in Midilist and -1:
then delete your current pull request.
This is what I'm looking for... how?
-
@d-healey I closed it, is that good?
-
@ustk Yeah
-
@d-healey Ok. There's still a "delete branch" button but I'm a bit afraid of this one...
I already fucked up my develop a few days ago, so never be stupid twice the same week :) -
@d-healey Ok so the thing now is that I still have all the commits in my develop. So I have to be careful not to make a pull request from develop until Christoph merges the separate ones.
-
@d-healey No in fact it's not as easy. Obviously I can't create a branch based on develop until I removed all these commits from it. And I'd prefer a delete over a dirty revert so I'll try to delete them first.
-
@ustk Give me a few minutes and I'll give you a solution
-
You can make a new branch based on any commit hash, or just based on Christoph's latests develop branch.
-
@d-healey Yeah new branch from a specific commit is the way to go. But I have a freakin authentication issue now, the git api messed up the authentication so the Desktop app is blocked too
You'll have to wait for me to fix this then after that I'll make the pull requests -
You'll have to wait for me to fix this then after that I'll make the pull requests
No rush. It's always a pain setting up a new workflow like this but once you get it it makes things easier :)
-
@d-healey That's done :) although because I had n older commit, it is showing up in the pull request. I realized I could even base the new branches on an even older commit but it's too late... It'll be easier next time when my origin will be even with the upstream.
-
@ustk My solution is to always branch from Christoph's develop branch, that way it doesn't matter how messed up my own fork is.
-
I believe the desktop version may have it as well; I only recently discovered it. Cherry-pick allows you to separate each pull request into its own branch, ensuring that no changes you make are added to the same pull request.
-
@Shannon-Burns Yes GitHub Desktop has cherry-pick. That's what @d-healey explained to me above about new branches for pull requests that I'd never thought of...