Sam Vilain <sam@vilain.net> wrote:
quoted text
> ok.  Well, perhaps a nice solution might be just to aggregate the
> comments as each new commit is made.  ie, the previous comment is
> prepended to the new comment unless you use the editor or a special
> -M (or whatever) option that replaces the running comment.

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.
 
quoted text
> I tried importing a patchset into pg, and made some changes to it to see
> the patch revisioning going on.  However, I can't see this happening.
> Can you perhaps include this information in your tutorial?

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.

quoted text
> As far as other, more general critiques of the software goes:  What
> about merging?  stgit has a very nice way of merging; I specify how to
> merge using a config file, and when I rebase my patches with "stg pull",
> it fires up my custom editor.  All I really want is a way to specify how
> to handle merges, with the ancestor/left/right files on hand.  I want to
> use something as simple as this script:
> 
>     echo "falling back to ediff-merge"
>     emacs --eval "(ediff-merge-files-with-ancestor \"${branch1}\"
>                    \"${branch2}\" \"${ancestor}\" nil \"${output}\")"

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.

quoted text
> That's all the features I'm really after.

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

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html