Re: PostgreSQL Developer meeting minutes up
От | Nicolas Barbier |
---|---|
Тема | Re: PostgreSQL Developer meeting minutes up |
Дата | |
Msg-id | b0f3f5a10906070026y148ac0a6nc3abe13923b93990@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL Developer meeting minutes up (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: PostgreSQL Developer meeting minutes up
|
Список | pgsql-hackers |
2009/6/7 Markus Wanner <markus@bluegap.ch>: > However, there's no special whitespace treatment. Nor anything remotely > as clever as "nearby variable renaming". There's no such magic, the > developer still needs to tell the tool what he wants. If I understand correctly, "nearby variable renaming" refers to changes to the few lines surrounding the changes-to-be-merged. There is certainly supposed to be an advantage relative to diff/patch here: as all changes leading to both versions are known (up to some common ancestor), git doesn't need "context lines" to recognize the position in the file that is supposed to receive the updates. Example: Original file: a b c Random other changes later (a and c are updated to incorporate "nearby variable renaming" or somesuch): extra line a' b c' (Note that the extra line is important, because if the line numbers stay the same and the lines-to-update are exactly the same, patch could just ignore the context lines.) An update to line b yields: extra line a' b' c' This change would not be diff/patch-mergeable to the original file, because the "context lines" a' and c' wouldn't be found. Git is smarter than this and doesn't need the context lines; rather it uses the full history to determine that the change to line 3 becomes a change to line 2 in the original file. It therefore merges this change to yield: a b' c Disclaimer: I don't use git, but I assume that this is how all systems that are smarter than diff/patch work. Nicolas
В списке pgsql-hackers по дате отправления: