StGIT and rerere

StGIT and rerere

[Robin Rosenberg]

Hi,

It seems stgit does not use git-rerere, so why not? Any reason other than it
hasn't been done yet?

I abuse stgit heavily, by frequently reording patches, which for some patches
result in re-occuring conflicts. git-rerere seems to be the solution.

What's the "rules" for when to invoke rerere? It seems it is mostly automatic 
in git, but since only the porcelainish commands use it, that means StGIT 
doesn't.

So here is what I *think* needs to be done. Seems simple enough.

stg push, stg pick, stg import, stg goto, stg fold, stg float
	do what push does and invoke git-rerere at the end whether the push ends with 
conflicts or not

stg pop
	nothing, or do I need to remove rr-cache/MERGE_RR, like git-reset does?

stg status --reset, stg push --undo
	remove rr-cache/MERGE_RR ?

stg refresh
	do what stgit does normally and then invoke git-rerere

stg resolved:
	do what stgit does normally and then invoke git-rerere

stg clean, stge delete:
	remove rr-cache/MERGE_RR ?

Anything else or comments on this list?

-- robin

Re: StGIT and rerere

[Catalin Marinas]

Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> It seems stgit does not use git-rerere, so why not? Any reason other
> than it hasn't been done yet?

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.

> I abuse stgit heavily, by frequently reording patches, which for
> some patches result in re-occuring conflicts. git-rerere seems to be
> the solution.

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.

> What's the "rules" for when to invoke rerere? It seems it is mostly
> automatic in git, but since only the porcelainish commands use it,
> that means StGIT doesn't.

It could probably be invoked by stgit.git.merge() if the git-read-tree
(and maybe the diff3 merge) failed (BTW, I replaced git-read-tree with
git-recursive-merge in my local tree and seems to detect renames
properly; I'll push it once I'm convinced there are no problems).

Note, however, that I haven't looked at how git-rerere works and I
might have misunderstood its functionality.

> So here is what I *think* needs to be done. Seems simple enough.
>
> stg push, stg pick, stg import, stg goto, stg fold, stg float do
> what push does and invoke git-rerere at the end whether the push
> ends with conflicts or not

the git.merge() function handles all the merges.

> stg pop
> 	nothing, or do I need to remove rr-cache/MERGE_RR, like
> git-reset does?

I think pop shouldn't do anything.

> stg status --reset, stg push --undo
> 	remove rr-cache/MERGE_RR ?

Yes (not sure for push --undo).

> stg refresh
> 	do what stgit does normally and then invoke git-rerere

Why should it invoke git-rerere? This just creates a commit. Or is it
needed for storing rerere ids?

> stg resolved:
> 	do what stgit does normally and then invoke git-rerere

No need to call rerere here since resolved is an StGIT-only function,
it doesn't affect the repository (it just unmarks the conflict files
so that stgit allows you to refresh).

> stg clean, stge delete:
> 	remove rr-cache/MERGE_RR ?

That's not needed. Delete can act like pop for the top patch.

-- 

Re: StGIT and rerere

[Junio C Hamano]

Catalin Marinas <catalin.marinas@arm.com> 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.