On Tue, Jan 23, 2007 at 08:11:38PM -0800, Linus Torvalds wrote: > Git *very* fundamentally tracks project state, not file state. Which means > that you very much can NOT try to "merge a file". It is a senseless > operation in git, and in fact, any SCM that allows it pretty much is > doomed to be a total piece of sh*t (*). > (*) And I'm not saying that just because git doesn't do it. It's much > more fundamental than that. Once you start doing per-file branching and > merging, you've basically screwed yourself, and you'll never be able to > work on the project as a "whole project" any more - you no longer have a > well-defined history that actually is the history of the whole project. In fact, I came some time ago on a workflow which could be seen as quite similar to this issue. The problem was about merging a new upstream release in a local branch, when both branches had heavy changes. Indeed this tree was not using GIT but CVS, with upstream tarballs imported on a branch - I just asked myself how it could be best handled with GIT, and could only come to the conclusion that something in GIT was still missing. What was particular about this tree, is that we are several people working on it, namely developpers taking care of the app, and me as build manager taking care of the build mechanics as well as kernel+OS. So the task was logically divided: one dev would merge the app, and I would merge everything else. As you see, it's far from one-file merges, but the problem is quite similar. The idea which I came up with was inspired by the "partial merge" feature in PRCS, which I had never used or even understood the purpose before that date. Basically, it was that if some set of files could be merged somewhat independently from the rest, and we don't want to get GIT attempt to merge them again when finally merging the whole, a commit of a partial merge would somehow record that some files had already been merged. And I happenned to think that it could be sufficient to create a commit that would not be a merge commit itself (since it is not a full-project merge), but which would instead reference "subcommits" for the relevant parts of the tree that were merged during that iteration. I realize that solution would not really be perfect, as there is always some coupling between the code and build stuff in a project. And sometimes we could want to get finer granularity than the file level. But that's so far my best guess at finding a solution. How would you handle such a situation ? Best regards, -- Yann. - 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