On Feb 13, 2008, at 12:39 AM, Johannes Sixt wrote:
Voltage Spike schrieb:
Third, git doesn't appear to have any sense of context when
performing a
merge. Another contrived example which wouldn't be flagged as a merge
conflict:
ptr = malloc(len); // Added in HEAD.
init(); // Included in merge-base.
ptr = malloc(len); // Added in "merge".
You seem to say that you want this to result in a merge conflict.
Yes, it appears that I wasn't clear that I see the above as a conflict.
I'm opposed to this: It means that you would mark a conflict if
there is a
single unchanged line between the two changes that come from the
merged
branches. So far it has happened for me much more frequently that such
merges were correct, and I should not be bothered with conflict
markers. I
conciously prefer to pay the price that such a merge is incorrect
on occasion.
That is why I'm hoping to make it configurable. I know that we have
more information than during a simple patch, but it seems odd that
changes can be occurring all around your local modifications and
you'll never be notified.
Which leads to a different point: does this lessen the value of
falling back to a 3-way merge during a rebase?
You also need to draw a border line: a single unchanged line
between the
changes? Or better also conflict at 2 lines? Or 3?
I naturally assumed the default number of context lines: 3. If I
recall correctly, this isn't typically configurable.
-
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
