Catalin Marinas <catalin.marinas@xxxxxxx> writes:
> I didn't know it exists. I've been thinking at a way to avoid
> duplicating the conflict fixing but haven't got to any results. This
> looks like a good idea.
> ...
> My problem was with maintaining a public branch where re-basing
> patches is not welcomed but I would still like to use StGIT in my
> development branch. When pulling from upstream in my devel branch, I
> get conflicts in some patches. The problem is that I get the same
> conflicts in the patches already merged in the public branch where the
> patches were previously checked in.
>
> Another case is several branches with common patches that generate
> conflicts.
> ...
> Note, however, that I haven't looked at how git-rerere works and I
> might have misunderstood its functionality.
I think Documentation/git-rerere.txt describes its operation in
enough details for the end user, but if there is anything
unclear please ask away.
There are two details that are not mentoined in the end-user
documentation.
* Identifying "same" conflicts.
This is done by hashing the text inside the conflict markers:
<<<<<<<
a
=======
b
>>>>>>>
Each conflicted section like the above are first canonicalized
so that section "a" sorts alphabetically earlier than section
"b" (in other words, if the conflict were <<< b === a >>> then
they are swapped to read <<< a === b >>>), concatenated and fed
into SHA-1 digest. The final digest after conflicted file is
read as a whole becomes the name of the conflict, and naming is
done per file.
The reason for this canonicalization is because the order in the
conflicted section depends on the direction of the merge (if
you pull test into master you get the conflict marked the other
way from the case you pulled master into test).
* rerere's resolution can affect outside conflict markers.
If an earlier conflict read like this:
...
z
<<<<<<<
a
=======
b
>>>>>>>
c
d
e
f
g
...
and your earlier resolution was like this:
...
w
b
dd
e
f
g
...
That is what rerere records (i.e. including removal of c and
change from z to w).
Then, when you see the same conflict like this (notice that g is
now h):
...
z
<<<<<<<
a
=======
b
>>>>>>>
c
d
e
f
h
...
it is resolved like this:
...
w
b
d
e
f
h
...
This is often useful when e.g. a <<< === >>> section changes
function signature of a (static) function; parts outside the
conflicted section needs matching changes to adjust to it and
that is recorded and replayed by rerere.
-
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