On Tue, Jul 12, 2011 at 12:40 PM, Andy Singleton <a...@assembla.com> wrote:
> Good point. If we allow foreign merges, then "log" and "blame" are not > going to work well. They will show changes coming from the merge, rather > than from the original commit. Fine. I'm willing to give up those details, > because merge is important. People will be happy with that if they give up > some detail and get a merge that works. If you want log and blame details, > then don't do foreign merges. I was not even speaking about foreign merges. I would be fine with supporting those but not with log/blame. I am just saying if you invent a new merge tracking format that you have to support it in log/blame/mergeinfo too. > I have made a specific proposal for handling moves and renames that is not > very complicated. Moves and renames can be identified by file name pattern > matching. This is the tactic that is used by git and subversion trumerge, > so we know it works well in practice. Once moves are spotted by the merge, > we can write the changes back in our merge commit, using the existing > copy+delete mechanism for writing moves. And, we can record the move in our > merge_history file so that changes can be mapped automatically in future > merges between between branches that don't have the move, and branches that > do have the move. Hmm, I guess I did not see your proposal as being specific. For example, trumerge works by doing some fairly extensive examinations of the entire repository history to build a cache of moves. It then constructs a merge script that it runs that does many merges to implement it. I am still not convinced this is easy. That said, IMO, this is the most important feature we need. So I am totally willing to give you some runway to go solve it. > This proposal is straightforward, but is not compatible with subtree > merginfo. It's pretty easy to do this mapping on one branch. It starts to > get complex and slow and problematic if you have to do it recursively on > subtrees. And, we can't record the mapping in the existing merginfo format. I get that you do not want to support subtree mergeinfo. I am simply saying why can't we invent a mechanism for a project to indicate that it does not want to allow subtree merges so that they can enjoy these new merge features? I think you have to invent this even if you create a new command, and I am just saying that once you invent this, you do not need a new command. -- Thanks Mark Phippard http://markphip.blogspot.com/
