On Wednesday November 09 2016 13:01:42 Christopher Jones wrote: >In my view, no it is not practical. Pull requests are to pull one branch, all >diffs, from one to another. This is why I maintain the sooner people get use >to the idea of making a separate branch for each piece of work, and pull >request, the faster they will make progress with working with git. This is >actually the power of git, not a hindrance. But it takes time for newcomers to >git to realise this ;)
So, the power of git is that it's not practical? A bit like how medicine is supposed not to taste good? :) I won't claim that being able to create pull request as currently the case doesn't have its use cases, but when you google around a bit I'm clearly not the only one who finds it, yes, a hindrance if the goal is to request inclusion of just a single file. If a change can be expressed as "please have a look at my version of this/ese file(s) and consider incorporating them", why would you have to jump through all kinds of hoops that only increase the chance for error? I wonder how many people will end up using and sharing their own complete ports tree over time, after all that's only a small step once you have taken the required steps to be able to make pull requests. As a *side remark*, there are at least 2 simple review boards that work with simple patches and don't require dealing with commits and branches: Review Board (www.reviewboard.org) and Phabricator (https://secure.phabricator.com/book/phabricator/article/installation_guide/). On Wednesday November 09 2016 14:24:36 Rainer Müller wrote: >You can delete commits completely from a branch by editing the history >with 'git rebase -i'. Even when the commit has been pushed (or in this case, was made directly on the remote)? Git makes that hard intentionally. I'm still surprised that I've been able to rewind the remote fork and delete a branch off it that had an open pull request, without recreating the whole fork from scratch. >to submit as a pull request. Always start these branches off the remote >that refers to macports, see 'git remote -v' which one this is. By default that'll be origin. >If you need to re-create changes you have already committed somewhere on >other branches, use 'git cherry-pick' to get these onto the pr-branch. This I think I'll continue to do the old-fashioned way, manually, just like I usually "rebase" by stashing my local patches (git stash or to a patchfile), pulling and reapplying my patches (which I only commit when they're about to be upstreamed). A bit more work but less error prone or at least when something does go wrong it's not because you misunderstood some intricate detail, and it's easier to back out of non-committed changes. > git log --graph --oneline --decorate @{upstream}..HEAD @{upstream}? Is that an existing keyword or something that you substitute automatically? R.
