git-checkout-branch | Switch git branch | Command Line Interface library

First, let's get pull out of the question, because pulling is a red herring: git pull means, roughly speaking, run git fetch, then run git merge. The action you're concerned with here is merging.

Update It is appearing unlikely that git supports something like this directly. I am looking into a mixed approach of cherrypicking individual files via a script that looks for new and modified entries only.

Let's go back to the basics: Git implements version control by making full snapshots of every file. These are in commits. Commits are numbered, with big ugly hash IDs. Each commit has two parts: the snapshot, and some metadata. The metadata shows who made the commit, when, and so on, and contains the number(s) of its parent commits.

Now look at your question again: you want new files and modified files. A commit, standing by itself, has no new files. It has no modified files. It has no deleted files. It just has files: it is simply a snapshot. You find something to be "new" or "modified" by comparing the snapshot to some other snapshot.

Which snapshot shall we compare, to which other snapshot? That's the key to solving your problem: you must pick the right set of snapshots and direct Git to do the right comparisons. Do you want one single comparison? Do you want many comparisons? Which ones do you want done, when, and what do you want to do with each comparison's result?

Realizing this, and looking at how git merge itself operates, will tell you whether git merge can be helpful. Knowing this, and looking at how git cherry-pick works, will tell you whether git cherry-pick can be helpful. Or, perhaps you should simply write your own tool—a script that invokes various Git plumbing commands¹ that will do what you want done.

¹Git divides its commands into porcelain or user-facing commands, vs plumbing commands. These are typically tools to do some specific job, but porcelain commands typically offer both options and user configuration. For instance, git pull runs two Git commands, but some users want the second command to be git rebase instead of git merge, so you can configure git pull to run git rebase instead of git merge. That in turn means that if you are 100% sure you want, in some script, to run git fetch followed by git merge, you should not use git pull because it might run git rebase instead!

Git's attempt to divide these is not completely successful, but some commands, such as git for-each-ref and git rev-list, are definitely not end-user-oriented, while others like git log and git diff are, or try to be. The git diff command has multiple plumbing commands that implement various parts: git diff-index, git diff-tree, git diff-files. None of those read user configuration. The git diff porcelain command does read user configuration. So in a script, you would generally want to figure out which plumbing command to use, so as not to have your script break due to user configuration.

Merge is a big and complicated command, but if we ignore various options, such as --squash, and edge cases such as when git merge does a fast-forward instead of merging, it ends up being relatively simple for most cases:

• The merge operation takes two commits: the current commit, at the tip of the current branch, and some other commit, at the tip of some other branch.

• Merge uses the commit graph to identify a merge base commit. This is the best common commit: of all the commits that are on both branches, one of them is "best". (Technically this is the Lowest Common Ancestor of the DAG formed by the commits' parent/child relationships in the commit graph.)

• Merge now performs not one but two diffs. The two diffs compare the common ancestor—the merge base—to each of the two branch tip commits: