Bill Priest wrote: > I understand what git is doing in terms of trying to > merge. But it sounds like it is enforcing policy on > the merge by not allowing me to check in files as I > resolve them. I have two separate branches w/ a > similar but not identical hardware platform where I > will always get conflicts when I merge back and forth. > Usually I cherry-pick between the two branches and > this works until there are massive changes on one > branch w/o time to move the changes to the other. In > the latter case I do a merge and live w/ resolving > conflicts.I guess w/ this workflow I have more > conflicts than is "normal". > > It seems pretty heavy handed to force all merges to be > complete before I can commit any files; git knows > which files are unmerged. Does git track which files > have been merged w/ conflicts? I'd like the option to > be able to check in files that I have indicated have > conflicts resolved (maybe w/ a flag to bypass the > checking). Yes, git does track which files have conflict, but I don't think it does track which files were merged on file-level without conflicts. The problem is that git remember which files are yet not resolved, and remembers that it is in the middle of the merge by remembering parents of a merge. So I think if you want to commit before doing merge, you would have to move MERGE_HEAD away, and commit specifying paths using "git commit <file1> <file2>". Or you can always resort to low-level plumbing, for example creating temporary staging area (index) etc. But if you want to just make some commit to be cherry-picked for example before merge, I think it would be easier to just stash away merge, do a commit, then unstash it. -- Jakub Narebski Poland - 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
