Re: VCS comparison table
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Oct 26, 2006, 12:13 UTC
- Message-ID
- <200610261413.36445.jnareb@gmail.com>
- In-Reply-To
- <4540A1FE.4050300@ableton.com>
Nicholas Allen wrote:
Show 24 quoted lines
> 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