I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
- Maximum compatibility with other GIT porcelains.
pg was designed to interoperate with core GIT and the other
GIT porcelains as much as possible. GIT favorites like git-am
can be used to modify a pg managed patch, and vice-versa,
and without requiring changes to the other GIT tools.
- Simplified command line user interface.
pg tries to simplify GIT by 'hiding' the index and behaving like
more traditional SCMs which only look at `HEAD` (last commit)
and the working directory (files).
- Preserves change history of patches.
The complete change history associated with each patch is
maintained directly within GIT. By storing the evolution of a
patch as a sequence of GIT commits standard GIT history tools
such as gitk can be used.
- Its prune proof.
The metadata structure is stored entirely within the refs
directory and the object database, which means you can safely use
git-prune without damaging your work, even for unapplied patches.
- Preserves patch series during clone.
The metadata structure used by pg allows git-clone to preserve
the patch series information, without changes required to
git-clone. (Patch series information is not preserved during
git-pull/git-push however.)
- Mix and matching of changes (bug fixes/features).
By maintaining changes as individual patches it is possible to
apply individual changes to the current working directory and
to unapply them just as easily.
- Automatic detection (and cancellation) of returning patches.
pg automatically detects when a patch is received from
the upstream GIT repository during a pg-rebase and deletes
(cancels) the local version of the patch from the patch series.
The automatic cancelling makes it easy to use pg to track and
develop changes on top of a GIT project.
- Fast
pg operations generally perform faster than StGIT operations,
at least on my large (~7000 file) repositories.
And for those so inclined:
Homepage: http://www.spearce.org/projects/scm/pg/
GIT Repository: http://www.spearce.org/projects/scm/pg.git
--
Shawn.
On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:
quoted
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
Hm, is there any way to import an existing patch into pg?
Doh! I haven't needed to do that yet. I'll code up a pg-import
later tonight. But since git and pg play nice together you can
do this:
pg-new Patch-Name
git-apply the-patch-file.patch
pg-ci -m"Importing the-patch-file.patch..."
or even:
pg-new Patch-Name
git-am mbox
and keep the 'history' stored in the mailbox.
So pg-import won't amount to a very long script. :-|
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:18
Hi,
Dear diary, on Fri, Feb 10, 2006 at 08:59:14PM CET, I got a letter
where Shawn Pearce [off-list ref] said that...
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
it sounds interesting. I've been thinking about wrapping some patch
queue tool in Cogito (post-1.0) and pg might be a better choice than
StGIT.
One thing I dislike on both StGIT and pg is that they both try to
build a full-fledged porcelain on top of GIT, instead of just focusing
on the patch management, doing it well and providing a convenient user
interface (well, can't say about pg's interface, didn't try it yet).
Instead of having pg-add, pg-log, or pg-status it might be more fruitful
to contribute the features you are missing to git-core or Cogito.
But while it claims to be compatible with all the porcelains, it at
least cannot be clone by them. ;) The GIT repository is not quite a
valid GIT repository since it is missing the HEAD and Cogito clones
based on this file instead of just assuming that your head is on the
master branch.
Also, when cloning it gives me a little unnerving errors like
error: File 6427c0154400f578d9cdff178e01e946db6f714f
(http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
corrupt
(but strangely, fsck-objects later does not complain).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:18
Dear diary, on Fri, Feb 10, 2006 at 10:38:18PM CET, I got a letter
where Shawn Pearce [off-list ref] said that...
But two things happened:
1) Cogito didn't run well on a Solaris box I wanted to try and
use it in; apparently we don't have enough GNU shell commands
available and Cogito fell over. (But right now I'd bet pg
will behave the same if not worse. I haven't had time to try
it. *sigh*)
I'm always listening for bugreports. Besides requiring bash, Cogito _is_
expected to run on POSIX stuff!
2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
than 'git-log' and 'git-diff'. Call it future muscle memory?
I hadn't written either of these scripts so I was getting a lot
of '-bash: pg-log: command not found' errors from my shell.
So they both became 1 line wrappers around the git-core
versions, just to save my sanity.
I see. IIRC Catalin gave the similar reasoning. (Obviously, my
egoistical me might be just hurt by it not wrapping Cogito. ;))
quoted
But while it claims to be compatible with all the porcelains, it at
least cannot be clone by them. ;) The GIT repository is not quite a
valid GIT repository since it is missing the HEAD and Cogito clones
based on this file instead of just assuming that your head is on the
master branch.
I've seen the same. I think it is either a bug in my rsync script
or a bug in the GIT http clone code; because that is the current
tip commit of the master branch. And I've only seen that error for
the tip commit, and only if the object doesn't exist in the object
directory because I've done git-pack && git-prune-packed.
On a second thought, this is probably simply caused by the web server
not reporting 404 on missing files.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
On Fri, Feb 10, 2006 at 04:04:01PM -0500, Shawn Pearce wrote:
Greg KH [off-list ref] wrote:
quoted
On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:
quoted
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
Hm, is there any way to import an existing patch into pg?
Doh! I haven't needed to do that yet. I'll code up a pg-import
later tonight. But since git and pg play nice together you can
do this:
pg-new Patch-Name
git-apply the-patch-file.patch
pg-ci -m"Importing the-patch-file.patch..."
or even:
pg-new Patch-Name
git-am mbox
well, as my quilt tree is around 200 patches right now, that would be
annoying to have to do by hand :)
thanks,
greg k-h
One thing I dislike on both StGIT and pg is that they both try to
build a full-fledged porcelain on top of GIT, instead of just focusing
on the patch management, doing it well and providing a convenient user
interface (well, can't say about pg's interface, didn't try it yet).
Instead of having pg-add, pg-log, or pg-status it might be more fruitful
to contribute the features you are missing to git-core or Cogito.
Very valid points. Before writing pg I used Cogito exclusively
and found git-core too cumbersome to use directly. When I started
writing pg I didn't intend on replacing everything GIT and Cogito
offers; I was trying to only create the patch stack but still use
the Cogito tools for everything else.
But two things happened:
1) Cogito didn't run well on a Solaris box I wanted to try and
use it in; apparently we don't have enough GNU shell commands
available and Cogito fell over. (But right now I'd bet pg
will behave the same if not worse. I haven't had time to try
it. *sigh*)
2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
than 'git-log' and 'git-diff'. Call it future muscle memory?
I hadn't written either of these scripts so I was getting a lot
of '-bash: pg-log: command not found' errors from my shell.
So they both became 1 line wrappers around the git-core
versions, just to save my sanity.
I would agree with trying to integrate some of the workflow idealogy
presented by StGIT and pg into something more mainstream such as
git-core or Cogito. Right now I'm using pg as a proving ground to
feel out how some of that might work in one particular environment:
A development team I work with is stuck using PVCS Version
Manager 6. Moving source code from a developer to a tester is a
huge nightmare; not only must the developer check the code into
the version control system but he/she must also write a bug report
in a bug database to tell someone else to get the source file
and give it to the tester. Its a horrible workflow. GIT + pg +
additional custom scripts seems to be easing the pain somewhat;
but sadly we can't just rip out PVCS Version Manager and use GIT.
But while it claims to be compatible with all the porcelains, it at
least cannot be clone by them. ;) The GIT repository is not quite a
valid GIT repository since it is missing the HEAD and Cogito clones
based on this file instead of just assuming that your head is on the
master branch.
Fixed. That's my fault - my hosting provider doesn't have GIT
installed and thus I had to publish my repository over rsync+ssh.
But git-push doesn't support that protocol type anymore. :-| So
I packed everything into pack files, pruned the object directory,
and rsync'd it up. I guess my rsync script didn't copy HEAD.
I've seen the same. I think it is either a bug in my rsync script
or a bug in the GIT http clone code; because that is the current
tip commit of the master branch. And I've only seen that error for
the tip commit, and only if the object doesn't exist in the object
directory because I've done git-pack && git-prune-packed.
--
Shawn.
From: Sam Vilain <hidden> Date: 2016-06-15 22:42:19
Shawn Pearce wrote:
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
- Maximum compatibility with other GIT porcelains.
- Simplified command line user interface.
How do I edit the description of an existing patch using pg? Perhaps an
option to pg-push ?
Sam.
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
- Maximum compatibility with other GIT porcelains.
- Simplified command line user interface.
How do I edit the description of an existing patch using pg? Perhaps an
option to pg-push ?
There isn't any description associated with a patch beyond its name
(which can be changed with pg-rename). Unlike StGIT pg currently
doesn't store a description with each patch.
This is partly because I want pg to extract the comments given to
pg-ci to make the description of the patch during an export with
pg-export - but I haven't written the code to walk back along the
related commits and extract each comment. On the other hand this
might not be the best description for a patch. :-)
--
Shawn.
From: Sam Vilain <hidden> Date: 2016-06-15 22:42:19
Shawn Pearce wrote:
quoted
quoted
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
- Maximum compatibility with other GIT porcelains.
- Simplified command line user interface.
How do I edit the description of an existing patch using pg? Perhaps an
option to pg-push ?
There isn't any description associated with a patch beyond its name
(which can be changed with pg-rename). Unlike StGIT pg currently
doesn't store a description with each patch.
This is partly because I want pg to extract the comments given to
pg-ci to make the description of the patch during an export with
pg-export - but I haven't written the code to walk back along the
related commits and extract each comment. On the other hand this
might not be the best description for a patch. :-)
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.
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?
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:
#!/bin/sh
branch1="$1"
branch2="$2"
ancestor="$3"
output="$4"
echo "Merging:"
echo
echo " $branch1"
echo " - $ancestor"
echo
echo " with:"
echo
echo " $branch2"
echo " - $ancestor"
echo
echo " to: $output"
echo ""
echo -n "Trying diff3..."
if diff3 -L local -L older -L remote -m -E "$branch1" "$ancestor" \
"$branch2" > "$output"
then
echo "OK"
else
echo "failed"
echo "falling back to ediff-merge"
emacs --eval "(ediff-merge-files-with-ancestor \"${branch1}\"
\"${branch2}\" \"${ancestor}\" nil \"${output}\")"
fi
Those commands I got from the default .stgitrc config.
That's all the features I'm really after.
Sam.
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.
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.
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.
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.
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:19
Hi,
Dear diary, on Fri, Feb 10, 2006 at 10:17:40PM CET, I got a letter
where Petr Baudis [off-list ref] said that...
quoted
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
it sounds interesting. I've been thinking about wrapping some patch
queue tool in Cogito (post-1.0) and pg might be a better choice than
StGIT.
so I've used it a bit and I'm going back to StGIT, at least for now.
It is not really usable for me so far, since it is missing two crucial
things:
* Patch description tracking. Patch description is almost as
important as patch contents for me, and pg just doesn't track it
for now. It would be best if it just seeded the patch
description by the first commit message and then allow you edit
it at the refresh time.
* Mail interface. StGIT can pre-fill the patch description with
my signoff line, but more importantly when I write
stg mail patchname
it will mail the patch to the addresses I configured it to,
prepend [PATCH] to the subject line and stuff.
So, my patchqueue workflow is "I do some random third-party patches
for some software and want to manage, update, and submit them easily."
PG does not make it much easier now, unfortunately.
Some common gripes for both StGIT and pg (well, I'm using some
ridiculously old StGIT version, so this may not apply anymore there):
* stg new --force - seriously, what's the point?! I always to
the change first and when it's any good, I want to create a
patch for it.
* I can't just get the patch in its "canonical ready-to-mail
form" on stdout so that I could easily review it. Why is
pg-export insisting to dump it to a file?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
* I can't just get the patch in its "canonical ready-to-mail
form" on stdout so that I could easily review it. Why is
pg-export insisting to dump it to a file?
I pushed tonight 2 patches for this. One of them adds a --stdout option
to 'export' so that you can see the patches. The other patch adds a
--mbox option to 'mail' that generates an mbox file on the stdout. This
is useful not only for reviewing patches.
--
Catalin