Re: [ANNOUNCE] pg - A patch porcelain for GIT

Sam Vilain <sam@vilain.net> wrote:

Yea, that's not a bad idea.  If you are creating a new commit you
probably would want to edit the running description for the patch;
or at least be reminded of what it is.
 

Revisioning doesn't happen for the series, just the individual patches. But I've thought about series revisoning and keeping a secondary GIT index/commit chain external to the main repository for exactly this purpose.

Each change to a patch (pg-ci) is a new commit object in GIT with the prior commit object as its parent; if you use pg-ci a few times with the same patch on the stack then look at the log with git-log or gitk you'll see the commits are chained together.

When you pop patches and reorder them in the series the resulting merges are stored as commits with two parents: one for the HEAD at the time of the merge and one for the commit which was the last commit in the patch being pushed (HEAD^1 and HEAD^2 respectively). For example:

	pg-new A
	echo a >>somefile
	pg-ci -m"This is a"
	pg-new B
	echo b >>somefile
	pg-ci -m"This is b"

	pg-pop -a
	pg-push B  # base used to be HEAD+A, now its HEAD
	pg-push A  # base used to be HEAD, now its HEAD+B

The challenge then becomes walking through the merge history. If you look at pg's own history you'll see an interesting knot in gitk at a7e73545e511c5c2daea1f6c7bf06cf3179e7f0da (Refreshed patch Create-Rebase-Tool). This was produced because I reorded the patches in the stack and thus had to merge them. It was an automatic merge, but it still generated merge commit objects.

Good suggestion about including some details about it in the tutorial.

pg doesn't currently invoke any user code when an automatic merge fails during pg-push or pg-rebase. It does attempt to produce a 3 way merge and leaves the resulting portions for you in the filesystem. If you look at MERGING.txt you'll see that up to 5 files can come out of a merge (here I'm using the tracked file X.c):

	X.c
	X.c-head
	X.c-last
	X.c-pbase
	X.c-rej

These just get left in the filesystem for you to use as you want; in your case it sounds like you'd want to invoke:

	emacs --eval "(ediff-merge-files-with-ancestor
		\"X.c-head\"
		\"X.c-last\"
		\"X.c-pbase\"
		nil
		\"X.c\"
		)"

X.c already contains the result of performing:

	diff X.c-pbase X.c-last | patch X.c

so it already has any hunks which were part of your patch and which applied cleanly to X.c-head (which is the file coming in as the new base). Thus you are left only with the rejecting hunks, which are in X.c-rej.

Personally I've always preferred being given the rejects from patch to work out a merge problem then to be given the mess that RCS merge leaves you with. (I've _never_ been able to decipher what I want from an RCS merge conflict.)

What is the desired behavior when multiple files have conflicts? Stop and let the user work on one file before moving to the next? Open all merge editors in parallel? Neither seems right to me in all situations, which is why I just left the `mess' in the filesystem for the user to resolve at their own pace.

I like what you are suggesting and will try to incorporate these improvements this week.