On 2016-11-09 13:51, René J.V. Bertin wrote:
> 1- Initially I followed github's suggestions as usual and added a
> README.md (in a first commit), thinking I'd be able to avoid that
> file easily enough. Instead it appears that pull requests can not be
> made for a specific commit or file/directory; README.md was an
> unintended part of my request. When I removed the file the pull
> request showed the addition and removal and I'm quite sure the same
> would have been true for a reverse commit. I managed to back out and
> recreate the branch, but it's highly annoying you only find out such
> things after doing a commit. Is there a way around this, or are pull
> requests always a reflection of the difference between the original
> master/head and the fork's head? IOW, is it going to be necessary to
> use 1 branch per pull request? That'd make it very impractical to use
> a single ports tree as both a local source for installed ports and a
> source for pull requests ...

Yes, you have to use a separate branch for each pull request. The pull
request will present the changes that where made from the start of the
branch to the current HEAD of the branch.

You can delete commits completely from a branch by editing the history
with 'git rebase -i'.

> 2- Suppose it *is* possible to have all local changes and custom
> ports in a single personal branch and then create pull requests when
> time and port are ripe. IIRC there's a magic incantation to rebase a
> topic branch on the remote origin/master (i.e. merge in remote
> changes on top of the changes in your topic branch without losing its
> history). Of course I haven't been able to retain that formula. It
> would be useful to describe the procedure on the working-with wiki.

You can keep other branches with other changes in the same repository.
You just have to be careful when you create a new branch that you intend
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.

For example, when "origin" is macports/macports-ports, create a branch
based on the current upstream master:

  git checkout -b pr-branch origin/master

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.
To see which commits will be submitted in a pull request, use:

  git log --graph --oneline --decorate origin/master..pr-branch

In general, if you created the branch as described above, the following
command will be identical when you are on the pr-branch. I use an alias
for this to quickly check which changes are "new" the current branch:

  git log --graph --oneline --decorate @{upstream}..HEAD

Rainer

Reply via email to