Chris Marshall venit, vidit, dixit 13.08.2009 22:16: > Suppose that merging branch dev1 into master would result in three files, f1, > f2, and f3 being changed, and that I only want to merge the changes for f1 and > f2 and not the changes for f3 currently. Later on, I want to accept the f3 > changes. Suppose further that the changes to f1, f2, and f3 occurred in a > single commit to branch dev1. > > What is the simplest way to use git to achieve that effect? > > More generally, I need a way to accept the changes for one or two files while > rejecting the changes for a potentially large number of files, then later on > accepting the changes for the large number of files. > > I work at a company where perforce is currently used for all development and am > trying to work out the git equivalents to all of the perforce flows we use. > This workflow is the only one that I am stumped on. > > One solution that occurs to me is to create a temporary branch off of the (most > recent) common ancestor of master and br1, let's say br2, checkout the files > from br1 that I want to merge into master and commit those to br2, then merge > br2 into master: > > git checkout common_ancestor_commit > git checkout -b br2 > git checkout br1 f1 f2 > git commit > git checkout master > git merge br2 > git branch -d br2 > > This strikes me as not too bad of a procedure, as long as there is a graceful > way of determining the most recent common ancestor of br1 and master. What's > the simplest way of doing that? > That would be simply git merge-base master br1. BUT: The main problem here is that git is not file based, but revision/commit/tree based. In the above, you're basically losing all the history common_ancestor_commit..br1 which produced br1's version of f1 and f2, in the sense that a git log master will not show that part of the history at all. If it makes sense to change f1 and f2 without changing f3 that probably means that the pertinent commit should have been split. Is it an option for you to rewrite br1's history? That would be the most gittish solution. Alternatively, you could git checkout master git merge --no-commit br1 git checkout --ours f3 git commit # add a note about f3 in the commit message That way at least you have the full history on master. Note that this will tell git that br1 is merged in, that is you can't use merge later on to pull in the changes to f3. Then, when you want to get that change to f3, you can br1's version of f3 using git checkout br1 -- f3 and committing that to master. But you should really rewrite br1 ;) Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html