Re: detecting rename->commit->modify->commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 1, 2008 at 4:09 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, May 01, 2008 at 05:54:06PM +0300, Ittay Dror wrote:
>
>  > Also, would anyone like to comment on:
>  > http://www.markshuttleworth.com/archives/123 (Renaming is the killer app
>  > of distributed version control
>  > <http://www.markshuttleworth.com/archives/123>)?

I'll just make the obvious point that he's talking about a problem and
an underlying cause:

The problem is not being able to successfully merge branches as time
goes by when one branch has had some renaming. He's decided the root
cause is not have an explicit representation of renames which would
enable the merges to succeed. So there are two questions:

1. Does development often happen where files get renamed and then
modified significantly in a distributed fashion but it is still
sensible to automatically merge the results?

2. Do you need explicit rename tracking to do an automatic merge in those cases?

I suspect that for 2 you don't in theory but considering all the
non-obvious possibilities would slow down the normal case of a
standard merge.

-- 
cheers, dave tweed__________________________
david.tweed@xxxxxxxxx
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux