On Tue, Jul 12, 2011 at 12:40 PM, Andy Singleton <andy_at_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/
Received on 2011-07-12 18:46:41 CEST