Re: detecting rename->commit->modify->commit
- From
- David Tweed <david.tweed@gmail.com>
- Date
- May 1, 2008, 15:30 UTC
- Message-ID
- <e1dab3980805010830l49e7d126pa4de831c174eda0c@mail.gmail.com>
- In-Reply-To
- <20080501150958.GA11145@sigill.intra.peff.net>
On Thu, May 1, 2008 at 4:09 PM, Jeff King <peff@peff.net> wrote:
Show 6 quoted lines
> 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@gmail.com 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