VCS comparison table
Jakub Narebski
jnareb at gmail.com
Thu Oct 26 13:13:35 BST 2006
Nicholas Allen wrote:
> Jakub Narebski wrote:
>>
>> 4. Supports Renames. I could agree with "Somewhat" because of not yet
>> implemented --follow option to git-rev-list (and therefore all porcelain).
>> Perhaps it would be closer to truth to leave the marker (background color)
>> as for "Somewhat" and write "N/A" with note that Git has contents and
>> pathname based heuristic detection of renames, or just put "Detect" or
>> "Detection" here.
>>
>> I would certainly change description of what means that SCM doesn't "Support
>> Renames" or has it implemented partially. Current explanation relies
>> heavily on _implementation_. The correct wording of current definition
>> would be that SCM doesn't support renames if history of a file "as visible
>> to SCM" is broken into before rename and after rename part, and that SCM
>> support it partially if you can track history of renamed file from
>> post-rename name but there is left in void history of pre-rename file.
>> But with this definition Git _does_ "Supports Renames".
>
> I would have thought that supports renames would also involve flagging a
> conflict when merging a file that has been renamed on 2 separate
> branches. ie 2 branches rename the file to different names and then one
> branch is merged into the other. In this situation, the user should be
> told of a rename conflict. Bzr supports this as far as I know. Not sure
> about git though as I have never used it.
If I remember correctly Git usually resolves such conflict. If it cannot
resolve it, it tells user of rename conflict (add/add conflict or rename/add
conflict).
Unfortunately Git tutorial part 3 on merges is not yer written.
--
Jakub Narebski
Poland
More information about the bazaar
mailing list