When merging a pull request there might be conflicts which need to be resolved prior to merging.
Basically, there are 2 ways:

• rebase on top resolving conflicts
• pull target branch and resolve conflicts

The pull approach results in an additional merge commit (that resolves conflicts) in a branch before merging, and I don't want that:

As can be seen, the branch has a node B that contains relevant to node A changes. I would like the history for a branch to contain only relevant changes.

If I do a rebase, the branch's history will indeed contain only relevant changes. Though it will be ambiguous if node B's changes are dependent on those that have been introduced by node C.

Changes within node B and node C are logically mutually independent. They directly modify node A.

Here is a file for node A:

first line: text node A
second line to be removed later
third line: text node A

node C modifies only the first and the third lines:

first line: node C text
second line to be removed later
third line: node C text

node B just deletes the second line:

first line: text node A
third line: text node A

While logically I don't see here any conflicts (changes from both nodes modify different lines), git however will fail to automatically resolve conflicts.

1. Can I resolve changes within a merging commit for an initial pull request?
2. Can such conflicts be resolved automatically in the first place?
3. Why does git see conflicts when changes affect different lines?

I want to maintain git history as clean as possible between releases. It should be apparent to an observer which changes are dependent on each other and which are not. Applying independent changes directly to a "base" (release commit) node A help to minimize mutations for the main branch.

CodePudding user response：

Your three questions might be better split up into at least two separate StackOverflow questions, but let's try this:

1. Can I resolve changes within a merging commit for an initial pull request?

Git itself does not have "pull requests", in the sense that GitHub or Bitbucket have pull requests. Git merely has commits, and individuals who have Git repositories can obtain and/or make new commits, including merge commits, using commands like git fetch and git merge, which—when combined into a single command-line command–can be spelled git pull. The git request-pull command generates an email message, which you can then send with any email-sending program, that asks someone else to "pull" some commits.

Since Git lacks these kinds of pull requests in the first place, the short answer is "no". If we look at sites like GitHub and Bitbucket, the answer depends on the hosting site. As far as I know, the current answer for GitHub is still "no", although it might be nice if they had a feature where you could provide the suggested final merge commit as well.¹ I have not used Bitbucket enough to get to the point where I could even speculate on their case.

2. Can such conflicts be resolved automatically in the first place?

No (but see below).

3. Why does git see conflicts when changes affect different lines?

The two changes that are to be combined abut (touch at the edges). Merge algorithms do exist that don't consider these to be conflicts, but experience has shown that the results are too-often broken. So merge algorithms that do consider these to be conflicts are the ones used (this is the reason for the answer to question 2).

When not using hosting sites like GitHub, the usual procedure here (in my experience) is to do the merge directly into the target branch, resolve conflicts there, and commit. The resulting tree (source snapshot) is the same as the one you get by merging from the target branch, into the branch on which you make the PR, but there's no extra merge commit.

¹This would be technically possible, though how GitHub would hook this up as a user accessible interface, I don't know. When you generate a GitHub PR, GitHub will, internally:

• Run git merge to see if an automated merge works.
• If so, generate two labels, refs/pull/n/head and refs/pull/n/merge, pointing to the commit-to-be-merged and the test-merge result.
• If not, generate one label, refs/pull/n/head, pointing to the commit-to-be-merged. The test-merge result appears to be discarded.

Adding a third label that provides the proposed merge resolution, with a commit supplied by the person making the PR, might be reasonable. The complete details would be up to the hosting site, but there's no obvious external reason one could not even just use the refs/pull/n/merge label.