How to accept pull request partially?

Question

There are two forks, yours and others. In the second at the beginning there are several commits I need, and then unnecessary ones. How can I see only the first n commits from another fork?

Either you do not quite understand what a pull request is, or you described a little something that you really want to do .-.
And what you are describing is more like a partial acceptance of a pull request (if there was any such request).
@ D-side Yes, it requires a partial acceptance, the re-request can be done by yourself with someone else's fork, but there is no choice of commit, as far as I noticed, the request is made on the HEAD of the specified branch of the specified fork.

Pavel Mayorov Pavel Mayorov 48.9k five 50 110 · Accepted Answer · 2016-10-05T09:41:13

For starters, you should get PR to yourself in a local repository. If this does not happen automatically, this can be done by prescription in the help of Gitchab :

git fetch origin pull/{ID}/head

You can also get someone else's branch locally completely, to work with it:

 git fetch origin pull/{ID}/head:{local-branch}

Then you can do as ixSci told you:

 git merge {commit-SHA} git push

Do not forget to also close the PR in the web interface so that it no longer hangs.

ixSci ixSci 22k 3 33 54 · Answer 2 · 2016-10-04T09:53:47

It's simple, find commit SHA that interests you, and, being in the branch you need, it does:

 git merge <commit-SHA>

This command will add all the changes that have occurred since your and other people's branches diverged, up to the necessary fixation (commit), the SHA-identifier of which you indicated.

hmm, but this commit, to which I want to make a merge, is in another fork in a branch with the same name.
@sercxjo, the name of a branch in git is a convention, it has no meaning.

D-side D-side 22.4k four thirty 54 · Answer 3 · 2016-10-04T09:23:14

If there are few commits, then the easiest way is to download them to a local repository for freedom of action:

 git remote add форк URL_форка git fetch форк

... and then I can offer two options:

Plain
Find the necessary SHA-hashes of the necessary commits in the branch log:
```
 git log форк/ветка 
```
cherry-pick by / SHA hashes in order of their use:
```
 git checkout локальная_ветка git cherry-pick a1a1a1 b2b2b2 c3c3c3 # ^^^^^^ ^^^^^^ ^^^^^^ префиксы хэшей коммитов 
```
There is nowhere to make a mistake here, but if you are nervous, you can do this beforehand:
```
 git checkout -b ненужная_ветка локальная_ветка 
```
... and cherry-pick into it. When it will be what you (seemingly) need, send it to the main one, requesting "rewind" (extra insurance against unwanted effects):
```
 git checkout локальная_ветка git merge --ff-only ненужная_ветка 
```
Difficult (but can be more convenient)
Interactive rebase ( rebase -i ) is good when much of their history is common, and the differences are easy to solve:
```
 # сделать на ветке с нужными изменениями новую ветку git checkout -b новые_изменения форк/ветка # вычислить отсутствующие коммиты и перенести ветку на верхушку локальная_ветка git rebase -i локальная_ветка новые_изменения 
```
This displays a text editor with a list of новые_изменения that are in the новые_изменения , but not in the новые_изменения . Each line is one commit: the operation (it says what each of them does, by default pick the same as cherry-pick ), hash and description. After you close the editor, the designated section of the новые_изменения branch will be rewritten according to what you write in the editor.
By removing the appropriate line, you remove the commit (from the новые_изменения , but not from the original форк/ветка ). And other operations do not interest you at the moment.
The rewriting of history is a dangerous thing, so it is done in a new unnecessary branch, which can be banged if something goes wrong. And at the end of the procedure, you should have a branch that branches off from the top of your локальная_ветка and on top of it contains only the changes you need from the fork. You can do merge with --ff-only (see above).

Generally speaking , they do about the same thing. Interactive rebase only eliminates manual digging in the log.

sercxjo sercxjo 6.379 one 20 48 · Answer 4 · 2016-10-05T09:12:24

Found the following solution.

I prepared an import branch from the common between forks of a commit. and wrote the changes to the server:
```
 git branch import 0cc8d855adb457d1860d6e25cb93b6cc75d5a09d git push --all 
```
On the site I created a pull request with a fork in the new branch of interest and accepted it
I downloaded the changes of the new branch, found the commits of interest:
```
 git checkout import git pull origin import git log 
```
Merged to the desired commit. There are possible conflicts, but everything went smoothly.
```
 git checkout master git merge a9219aa49e31bd38a6e00b0c0b17428f3fe67229 
```
Recorded changes to the server.
```
 git push 
```

Partial pull request in a foreign fork can also be done by creating an additional branch in your fork.

one
Too hard. Enough was the last three teams. - Pavel Mayorov

How to accept pull request partially?

4 answers 4

Plain

Difficult (but can be more convenient)

More articles: