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.
This was fixed couple of weeks ago in the main branch. No need to pass
--force anymore.
* 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?
To view the patch you can use 'stg diff -r <patch>/' but it doesn't
show the description. Dumping the full patch on stdout would be
useful, indeed. The export and mail commands use different templates
and the latter even adds the standard mail headers. Which of these two
commands would you prefer to dump the patch on stdout (both is fine as
well)?
Another thing that's missing in StGIT is the import of a series of
patches. At the moment I run a small shell script to import individual
patches.
--
Catalin
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-14 09:26:41 +0000, Catalin Marinas wrote:
Another thing that's missing in StGIT is the import of a series of
patches. At the moment I run a small shell script to import
individual patches.
One thing I would like to see in stgit is the opposite of "stg
commit"; instead of converting patches to regular commits, take the
topmost regular commits and convert them to patches.
For example, "stg uncommit foo bar baz" would -- regardless of any
existing patches, applied or not -- convert the top three regular
commits, with comments and all, to stgit patches called foo, bar, and
baz. These would be already applied, at the bottom of the stack. I
imagine all one would have to do is to modify some stgit metadata, so
the operation could be really cheap.
Of course, "stg uncommit" is allowed to reject any commit with more
than one parent, since those can't be represented as stgit patches.
This would perhaps not add much power to an all-stgit workflow, but it
would be a really convenient way to edit recent git history. Sort of
like a more convenient rebase. And a great way to lure new users. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: Chuck Lever <hidden> Date: 2016-06-15 22:42:19
Karl Hasselström wrote:
On 2006-02-14 09:26:41 +0000, Catalin Marinas wrote:
quoted
Another thing that's missing in StGIT is the import of a series of
patches. At the moment I run a small shell script to import
individual patches.
One thing I would like to see in stgit is the opposite of "stg
commit"; instead of converting patches to regular commits, take the
topmost regular commits and convert them to patches.
For example, "stg uncommit foo bar baz" would -- regardless of any
existing patches, applied or not -- convert the top three regular
commits, with comments and all, to stgit patches called foo, bar, and
baz. These would be already applied, at the bottom of the stack. I
imagine all one would have to do is to modify some stgit metadata, so
the operation could be really cheap.
Of course, "stg uncommit" is allowed to reject any commit with more
than one parent, since those can't be represented as stgit patches.
This would perhaps not add much power to an all-stgit workflow, but it
would be a really convenient way to edit recent git history. Sort of
like a more convenient rebase. And a great way to lure new users. :-)
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-14 10:22:51 -0500, Chuck Lever wrote:
Karl Hasselström wrote:
quoted
One thing I would like to see in stgit is the opposite of "stg
commit"; instead of converting patches to regular commits, take
the topmost regular commits and convert them to patches.
For example, "stg uncommit foo bar baz" would -- regardless of any
existing patches, applied or not -- convert the top three regular
commits, with comments and all, to stgit patches called foo, bar,
and baz. These would be already applied, at the bottom of the
stack. I imagine all one would have to do is to modify some stgit
metadata, so the operation could be really cheap.
Of course, "stg uncommit" is allowed to reject any commit with
more than one parent, since those can't be represented as stgit
patches.
This would perhaps not add much power to an all-stgit workflow,
but it would be a really convenient way to edit recent git
history. Sort of like a more convenient rebase. And a great way to
lure new users. :-)
i think you want "stg pick --reverse" ?
No, I literally want the opposite of "stg commit", so that the
sequence "stg commit; stg uncommit" has zero net effect.
Say we have the following situation (stack growing downward, of
course):
:
|
a
|
b
|
c <- bases/master
|
d <- applied patch "foo"
|
e <- applied patch "bar"; HEAD
|
f <- unapplied patch "baz"
|
:
In this situation, the hypothetical "stg uncommit" command would have
the following effect:
$ stg uncommit goo baa
:
|
a <- bases/master
|
b <- applied patch "baa"
|
c <- applied patch "goo"
|
d <- applied patch "foo"
|
e <- applied patch "bar"; HEAD
|
f <- unapplied patch "baz"
|
:
Note that HEAD is unchanged; the only thing that has happend is that
stgit has taken over the topmost two commits, and turned them into
patches. No git operations whatsoever have taken place; all stgit had
to do was change the value of bases/master and add bookkeeping
information for the two new patches.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: Chuck Lever <hidden> Date: 2016-06-15 22:42:19
Karl Hasselström wrote:
On 2006-02-14 10:22:51 -0500, Chuck Lever wrote:
quoted
Karl Hasselström wrote:
quoted
One thing I would like to see in stgit is the opposite of "stg
commit"; instead of converting patches to regular commits, take
the topmost regular commits and convert them to patches.
For example, "stg uncommit foo bar baz" would -- regardless of any
existing patches, applied or not -- convert the top three regular
commits, with comments and all, to stgit patches called foo, bar,
and baz. These would be already applied, at the bottom of the
stack. I imagine all one would have to do is to modify some stgit
metadata, so the operation could be really cheap.
Of course, "stg uncommit" is allowed to reject any commit with
more than one parent, since those can't be represented as stgit
patches.
This would perhaps not add much power to an all-stgit workflow,
but it would be a really convenient way to edit recent git
history. Sort of like a more convenient rebase. And a great way to
lure new users. :-)
i think you want "stg pick --reverse" ?
No, I literally want the opposite of "stg commit", so that the
sequence "stg commit; stg uncommit" has zero net effect.
gotcha.
well, that would work OK for maintainers, but would be kind of strange
for folks who are pulling from such a repository. how would that work?
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:19
Dear diary, on Tue, Feb 14, 2006 at 09:58:02PM CET, I got a letter
where Chuck Lever [off-list ref] said that...
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
It is ok as long as you know what are you doing - if you don't push out
the commits you've just "undid" (or work on a public accessible
repository in the first place, but I think that's kind of rare these
days; quick survey - does anyone reading these lines do that?), there's
nothing wrong on it, and it gives you nice flexibility.
For example, to import bunch of patches (I guess that's the original
intention behind this) you just run git-am on them and then stg uncommit
all of the newly added commits.
--
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: Sam Vilain <hidden> Date: 2016-06-15 22:42:19
Petr Baudis wrote:
quoted
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
It is ok as long as you know what are you doing - if you don't push out
the commits you've just "undid" (or work on a public accessible
repository in the first place, but I think that's kind of rare these
days; quick survey - does anyone reading these lines do that?), there's
nothing wrong on it, and it gives you nice flexibility.
Yes, and this is one problem I envision with publishing a git repository
with an stgit stack applied - somebody later doing a pull of it will not
find the head revision they had. I'm not sure what the net effect of
this will be, though.
Sam.
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
It is ok as long as you know what are you doing - if you don't push out
the commits you've just "undid" (or work on a public accessible
repository in the first place, but I think that's kind of rare these
days; quick survey - does anyone reading these lines do that?), there's
nothing wrong on it, and it gives you nice flexibility.
Yes, and this is one problem I envision with publishing a git repository
with an stgit stack applied - somebody later doing a pull of it will not
find the head revision they had. I'm not sure what the net effect of
this will be, though.
It would cause some pain for anyone pulling from it with git-pull, as
git-pull won't happily go backwards from what I've seen. But I think
you can force it to do so even if it won't make sense during the
resulting merge, which then leaves the user in an interesting state.
This is actually why pg-rebase doesn't care what you move to
when you grab the remote's commit; it just jumps to that commit
and pushes your patch stack back down onto it. So if the remote
rebuilds itself through a new commit lineage which you have never
seen before the next pg-rebase will still update to it. But on
the other hand if you have a commit that isn't in your local patch
stack its gone into the bit bucket.
Publishing a repository with a stg (or pg) patch series isn't
a problem; the problem is that no clients currently know how to
follow along with the remote repository's patch series. And I can't
think of a sensible behavior for doing so that isn't what git-core is
already doing today for non patch series type clients (as in don't go
backwards by popping but instead by pushing a negative delta). :-)
--
Shawn.
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:19
Dear diary, on Wed, Feb 15, 2006 at 01:35:10AM CET, I got a letter
where Shawn Pearce [off-list ref] said that...
Publishing a repository with a stg (or pg) patch series isn't
a problem; the problem is that no clients currently know how to
follow along with the remote repository's patch series. And I can't
think of a sensible behavior for doing so that isn't what git-core is
already doing today for non patch series type clients (as in don't go
backwards by popping but instead by pushing a negative delta). :-)
New Cogito will automagically do the right thing if you are just
fast-forwarding and you are using cg-update - if the branch rebased, it
will happily follow (but cg-fetch + cg-merge will NOT and it will fall
back to the tree merge).
--
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: J. Bruce Fields <hidden> Date: 2016-06-15 22:42:19
On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:
Publishing a repository with a stg (or pg) patch series isn't
a problem; the problem is that no clients currently know how to
follow along with the remote repository's patch series. And I can't
think of a sensible behavior for doing so that isn't what git-core is
already doing today for non patch series type clients (as in don't go
backwards by popping but instead by pushing a negative delta). :-)
If you represent each patch as a branch, with each modification to the
patch a commit on the corresponding branch, and each "push" operation a
merge from the branch corresponding to the previous patch to a branch
corresponding to the new patch (isn't that what pg's trying to do?),
then it should be possible just to track the branch corresponding to the
top patch.
In theory I guess it should also be possible to merge patch series that
have followed two lines of development, by merging each corresponding
branch.
The history would be really complicated. You'd need to figure out how
to track the patch comments too, and you'd need scripts to convert to
just a simple series of commits for submitting upstream. Probably not
worth the trouble, but I don't know.
If you really want revision control on patches the simplest thing might
be just to run quilt or Andrew Morton's scripts on top of a git
repository--the documentation with Andrew's scripts recommends doing
that with CVS.
--b,
On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:
quoted
Publishing a repository with a stg (or pg) patch series isn't
a problem; the problem is that no clients currently know how to
follow along with the remote repository's patch series. And I can't
think of a sensible behavior for doing so that isn't what git-core is
already doing today for non patch series type clients (as in don't go
backwards by popping but instead by pushing a negative delta). :-)
If you represent each patch as a branch, with each modification to the
patch a commit on the corresponding branch, and each "push" operation a
merge from the branch corresponding to the previous patch to a branch
corresponding to the new patch (isn't that what pg's trying to do?),
then it should be possible just to track the branch corresponding to the
top patch.
Yes that's pg in a nutshell.
But what happens when I pop back two patches (of three) and then push
down a different (fourth) patch? The tree just rewound backwards
and then forwards again in a different direction. (I apologize for
not being able to draw a nice ASCII art diagram of this, that's a
skill I'll have to learn to keep up with you guys.) This is the
issue with Junio's pu branch in git.git and is why some people
apparently don't follow it.
StGIT and pg aren't the only ones who suffer from this wonderful
little feature of GIT.
In theory I guess it should also be possible to merge patch series that
have followed two lines of development, by merging each corresponding
branch.
Of course. If I delete all of the refs used by pg to mark the patch
boundaries its just another GIT branch. Ditto for StGIT. So clearly
you can merge them together just like any other GIT branch.
The open question is could you preserve the patch boundaries
while doing the merge. Probably not. It would become way to
complicated as you would want to merge the entire branch and not each
individual patch as the individual patch merges may not work but the
larger branch merge might go through without human intervention.
Of course you can try to keep the patch boundaries by exporting
all of the patches from the one branch and push them on top of
the current branch. But isn't that what a 3 way merge is anyway?
And again that might not work as well as taking the larger patch
and pushing that down. :-)
The history would be really complicated. You'd need to figure out how
to track the patch comments too, and you'd need scripts to convert to
just a simple series of commits for submitting upstream. Probably not
worth the trouble, but I don't know.
I think I'm almost there with pg. One of my next tasks is the
patch log ripping code. This is really only complicated because GIT
won't let me store the base of a 3 way merge as part of a commit;
all I can store is the set of parents. If I had the base in the
commit (and specifically marked as such so I can tell it from the
end points) then I could easily walk through the log to extract all
commits relevant to a patch and seek forward and backward over it.
Perhaps I could cheat and record 3 parents: (HEAD, base, last).
I wonder what gitk would make of that mess. I doubt it would display
any better than the current (HEAD, last) format I'm using now.
If you really want revision control on patches the simplest thing might
be just to run quilt or Andrew Morton's scripts on top of a git
repository--the documentation with Andrew's scripts recommends doing
that with CVS.
True but you also then run into problems about needing to know which
base each patch revision was applied against so you can reproduce
a source tree plus patch at a specific point in time.
When I started pg I first thought about recording a patch in a
secondary index/working directory where each patch was its own file
and use git-diff-tree to extract the patch, commit it as a blob in
the secondary index/directory, and push it onto the series by reading
the blob in and running git-apply on the patch stored within it.
I ruled this strategy out as it just felt like it would be too
slow and rather unnatural to work on with existing GIT tools.
I didn't want to write a full porcelain; I was really hoping to just
extend Cogito to get a patch stack that worked the way *I* wanted a
patch stack to work, which was close to StGIT but not quite StGIT.
(Of course it didn't work out this way when I picked a prefix of
'pg' instead of 'cg' for my new commands.) :-|
--
Shawn.
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
Karl Hasselström wrote:
quoted
No, I literally want the opposite of "stg commit", so that the
sequence "stg commit; stg uncommit" has zero net effect.
well, that would work OK for maintainers, but would be kind of
strange for folks who are pulling from such a repository. how would
that work?
I didn't plan to publish branches where this kind of history munging
was being done. It's precisely like "git rebase" in that regard --
it's a tool for cleaning up history before it is published.
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs
out the original changes.
You don't change stuff that's already committed _and published_ (well,
except for pu branches :-). Rewriting history is perfectly OK up until
the moment someone has pulled your branch.
i'm speculating, but i suspect that's why there's a "stg pick
--reverse" and not a "stg uncommit."
I don't think I've been very successful in communicating exactly what
I want "stg uncommit" for. It's not that I want to undo a committed
change -- what I want is to transform it into an stgit patch so that I
can edit it with a minimum of effort.
$ edit edit edit
$ git-commit -a -m "create foo"
$ edit edit edit
$ git-commit -a -m "improve foo"
$ edit edit edit
$ git-commit -a -m "improve bar"
# Oops, I realize that the "create foo" changeset had a debug
# printout left in it, and I wasn't already using stgit.
$ stg init
$ stg uncommit improve-bar improve-foo create-foo
$ stg stg pop --to=create-foo
$ edit --remove=debug-printout
$ stg refresh
$ stg push --all
Similar use-cases for e.g. reordering commits, merging commits,
deleting one commit in the middle of a chain of good ones, etc. are
easy to come up with. The point is that stgit alreay handles all this,
_but only if you have been using stgit from the start_. What "stg
uncommit" does is basically to import (linear) git history into stgit,
where a powerful toolset exists to edit it.
You can actually do this today; just create a new branch where you
want your new stgit stack to be based, and "stg pick" the
commits/patches from the old branch:
$ git-checkout -b new-branch HEAD^^^
$ stg init
$ stg pick old-branch^^^ -n create-foo
$ stg pick old-branch^^ -n improve-foo
$ stg pick old-branch^ -n improve-bar
$ git-branch -D old-branch
$ git-checkout -b old-branch
$ git-branch -d new-branch
This series of commands also converts the top three commits to stgit
patches, and leaves the user on the same branch where she started (it
does _exactly_ the same job as "stg uncommit improve-bar improve-foo
create-foo"), but it's a lot of work, and a typo could lose commits.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:19
Karl Hasselström wrote:
On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
quoted
Karl Hasselström wrote:
quoted
No, I literally want the opposite of "stg commit", so that the
sequence "stg commit; stg uncommit" has zero net effect.
well, that would work OK for maintainers, but would be kind of
strange for folks who are pulling from such a repository. how would
that work?
I didn't plan to publish branches where this kind of history munging
was being done. It's precisely like "git rebase" in that regard --
it's a tool for cleaning up history before it is published.
quoted
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs
out the original changes.
You don't change stuff that's already committed _and published_ (well,
except for pu branches :-). Rewriting history is perfectly OK up until
the moment someone has pulled your branch.
quoted
i'm speculating, but i suspect that's why there's a "stg pick
--reverse" and not a "stg uncommit."
I don't think I've been very successful in communicating exactly what
I want "stg uncommit" for. It's not that I want to undo a committed
change -- what I want is to transform it into an stgit patch so that I
can edit it with a minimum of effort.
$ edit edit edit
$ git-commit -a -m "create foo"
$ edit edit edit
$ git-commit -a -m "improve foo"
$ edit edit edit
$ git-commit -a -m "improve bar"
# Oops, I realize that the "create foo" changeset had a debug
# printout left in it, and I wasn't already using stgit.
$ stg init
$ stg uncommit improve-bar improve-foo create-foo
$ stg stg pop --to=create-foo
$ edit --remove=debug-printout
$ stg refresh
$ stg push --all
The same workflow, with less hassle (and already implemented)
$ git format-patch -k HEAD~3
$ edit 0001-*
$ git am -k 000*
Similar use-cases for e.g. reordering commits, merging commits,
deleting one commit in the middle of a chain of good ones, etc. are
easy to come up with. The point is that stgit alreay handles all this,
_but only if you have been using stgit from the start_. What "stg
uncommit" does is basically to import (linear) git history into stgit,
where a powerful toolset exists to edit it.
You can actually do this today; just create a new branch where you
want your new stgit stack to be based, and "stg pick" the
commits/patches from the old branch:
$ git-checkout -b new-branch HEAD^^^
$ stg init
$ stg pick old-branch^^^ -n create-foo
$ stg pick old-branch^^ -n improve-foo
$ stg pick old-branch^ -n improve-bar
$ git-branch -D old-branch
$ git-checkout -b old-branch
$ git-branch -d new-branch
This series of commands also converts the top three commits to stgit
patches, and leaves the user on the same branch where she started (it
does _exactly_ the same job as "stg uncommit improve-bar improve-foo
create-foo"), but it's a lot of work, and a typo could lose commits.
Isn't this akin to what "git cherry-pick" does, except for the "convert
to stgit patches" thing?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-15 11:42:55 +0100, Andreas Ericsson wrote:
Karl Hasselström wrote:
quoted
You can actually do this today; just create a new branch where you
want your new stgit stack to be based, and "stg pick" the
commits/patches from the old branch:
$ git-checkout -b new-branch HEAD^^^
$ stg init
$ stg pick old-branch^^^ -n create-foo
$ stg pick old-branch^^ -n improve-foo
$ stg pick old-branch^ -n improve-bar
$ git-branch -D old-branch
$ git-checkout -b old-branch
$ git-branch -d new-branch
This series of commands also converts the top three commits to
stgit patches, and leaves the user on the same branch where she
started (it does _exactly_ the same job as "stg uncommit
improve-bar improve-foo create-foo"), but it's a lot of work, and
a typo could lose commits.
Isn't this akin to what "git cherry-pick" does, except for the
"convert to stgit patches" thing?
Yes, "stg pick" and git-cherry-pick are very similar as far as I know,
the only difference being that "stg pick" creates an stgit patch while
git-cherry-pick creates a regular commit. (And an applied stgit patch
is just a regular commit which stgit maintains some metadata about.)
However, using git-cherry-pick in this scenario would just recreate
the initial state exactly, since converting the commits to stgit
patches was what it was all about.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-15 12:25:02 +0100, Karl Hasselström wrote:
However, using git-cherry-pick in this scenario would just recreate
the initial state exactly, since converting the commits to stgit
patches was what it was all about.
"since" -> "and"
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
Dear diary, on Tue, Feb 14, 2006 at 09:58:02PM CET, I got a letter
where Chuck Lever [off-list ref] said that...
quoted
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
It is ok as long as you know what are you doing - if you don't push out
the commits you've just "undid" (or work on a public accessible
repository in the first place, but I think that's kind of rare these
days; quick survey - does anyone reading these lines do that?), there's
nothing wrong on it, and it gives you nice flexibility.
For example, to import bunch of patches (I guess that's the original
intention behind this) you just run git-am on them and then stg uncommit
all of the newly added commits.
This is a sensible way of using an uncommit command but I initially
thought it would be better to make things harder for people wanting to
re-write the history. Anyway, I'll keep this command on my todo list.
--
Catalin
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:42:19
On Wed, Feb 15, 2006 at 01:54:11AM -0500, Shawn Pearce wrote:
"J. Bruce Fields" [off-list ref] wrote:
quoted
On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:
quoted
Publishing a repository with a stg (or pg) patch series isn't
a problem; the problem is that no clients currently know how to
follow along with the remote repository's patch series. And I can't
think of a sensible behavior for doing so that isn't what git-core is
already doing today for non patch series type clients (as in don't go
backwards by popping but instead by pushing a negative delta). :-)
If you represent each patch as a branch, with each modification to the
patch a commit on the corresponding branch, and each "push" operation a
merge from the branch corresponding to the previous patch to a branch
corresponding to the new patch (isn't that what pg's trying to do?),
then it should be possible just to track the branch corresponding to the
top patch.
Yes that's pg in a nutshell.
But what happens when I pop back two patches (of three) and then push
down a different (fourth) patch? The tree just rewound backwards
and then forwards again in a different direction.
So you've got p1, p2, and p3 applied, each with its corresponding
branch--respectively, b1, b2, and b3. Popping two patches just checks
out b1, and doesn't affect the repository at all. If you push a new
patch, p4, you've just created a new branch, b4--you haven't touched the
existing branches. If you push p2 and p3 back on, you're just merging
the new changes from b4 into b2 and then merging the newly merged b2
into b3.
From the point of view of someone tracking b3, this is all fine. OK,
maybe it's excessively complicated, but pulls should work, because it
never sees history diseappear as it does when you represent each patch
with a commit on a single branch.
quoted
If you really want revision control on patches the simplest thing might
be just to run quilt or Andrew Morton's scripts on top of a git
repository--the documentation with Andrew's scripts recommends doing
that with CVS.
True but you also then run into problems about needing to know which
base each patch revision was applied against so you can reproduce
a source tree plus patch at a specific point in time.
Right, so you keep the tree under revision control as well as the
patches.
--b.
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-15 17:25:30 +0000, Catalin Marinas wrote:
On 14/02/06, Petr Baudis [off-list ref] wrote:
quoted
It is ok as long as you know what are you doing - if you don't
push out the commits you've just "undid" (or work on a public
accessible repository in the first place, but I think that's kind
of rare these days; quick survey - does anyone reading these lines
do that?), there's nothing wrong on it, and it gives you nice
flexibility.
For example, to import bunch of patches (I guess that's the
original intention behind this) you just run git-am on them and
then stg uncommit all of the newly added commits.
This is a sensible way of using an uncommit command but I initially
thought it would be better to make things harder for people wanting
to re-write the history. Anyway, I'll keep this command on my todo
list.
stgit rewrites history all the time anyway. And as far as I recall,
there's nothing in the documentation that warns the user not to
publish stgit-managed branches. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
Here is that uncommit command I was going on and on and on about.
There's also some stricter checking that refs/heads/bases is reset to
HEAD whenever we reach zero applied patches, since otherwise you can't
uncommit patches on an empty stomach.
Note the extremely cool feature that you can uncommit regardless of
how dirty your working tree is!
--
Karl Hasselström
@@ -0,0 +1,80 @@+__copyright__="""+Copyright(C)2006,CatalinMarinas<catalin.marinas@gmail.com>++Thisprogramisfreesoftware;youcanredistributeitand/ormodify+itunderthetermsoftheGNUGeneralPublicLicenseversion2as+publishedbytheFreeSoftwareFoundation.++Thisprogramisdistributedinthehopethatitwillbeuseful,+butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+GNUGeneralPublicLicenseformoredetails.++YoushouldhavereceivedacopyoftheGNUGeneralPublicLicense+alongwiththisprogram;ifnot,writetotheFreeSoftware+Foundation,Inc.,59TemplePlace,Suite330,Boston,MA02111-1307USA+"""++importsys,os+fromoptparseimportOptionParser,make_option++fromstgit.commands.commonimport*+fromstgit.utilsimport*+fromstgitimportstack,git++help='turn regular git commits into StGIT patches'+usage="""%prog [options] <patchname1> [<patchname2> ... ]++Takesoneormoregitcommitsatthebaseofthecurrentstack,and+turnsthemintoStGITpatches.Thesenewpatchesarealreayapplied,+atthebottomofthestack.Thisistheexactoppositeof'stg+commit'.++Youcaneithergiveonepatchnameforeachcommityouwishto+uncommit,orusethe--numberoptionandexactlyonepatchname;StGIT+willthencreatenumberedpatcheswiththegivenpatchnameasprefix.++Onlycommitswithexactlyoneparentcanbeuncommitted;inother+words,youcan't uncommmit a merge."""++options=[make_option('-n','--number',type='int',+help='uncommit the specified number of commits')]++deffunc(parser,options,args):+iflen(args)==0:+parser.error('you must specify at least one patch name')+ifoptions.number:+iflen(args)!=1:+parser.error('when using --number, specify exactly one patch name')+patchnames=['%s%d'%(args[0],i)+foriinxrange(options.number-1,-1,-1)]+else:+patchnames=args++ifcrt_series.get_protected():+raiseCmdException,'This branch is protected. Uncommit is not permitted'++print'Uncommitting %d patches...'%len(patchnames),+sys.stdout.flush()++forpatchnameinpatchnames:+base_file=crt_series.get_base_file()+commit_id=read_string(base_file)+commit=git.Commit(commit_id)+try:+parent,=commit.get_parents()+exceptValueError:+raiseCmdException,('Commit %s does not have exactly one parent'+%commit_id)+author_name,author_email,author_date=name_email_date(+commit.get_author())+crt_series.new_patch(patchname,+can_edit=False,before_existing=True,+top=commit_id,bottom=parent,+message=commit.get_log(),+author_name=author_name,+author_email=author_email,+author_date=author_date)+write_string(base_file,parent)++print'done'
@@ -621,7 +621,8 @@ class Series:unapplied=False,show_patch=False,top=None,bottom=None,author_name=None,author_email=None,author_date=None,-committer_name=None,committer_email=None):+committer_name=None,committer_email=None,+before_existing=False):"""Creates a new patch"""ifself.__patch_applied(name)orself.__patch_unapplied(name):
@@ -664,8 +665,13 @@ class Series:f.writelines([line+'\n'forlineinpatches])f.close()else:-append_string(self.__applied_file,patch.get_name())-self.__set_current(name)+ifbefore_existing:+insert_string(self.__applied_file,patch.get_name())+ifnotself.get_current():+self.__set_current(name)+else:+append_string(self.__applied_file,patch.get_name())+self.__set_current(name)defdelete_patch(self,name):"""Deletes a patch
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
Save the current HEAD into refs/heads/base if the stack is empty after
a patch has been deleted. This was not done before, which caused
refs/heads/base to not be updated after 'stg commit'. To guard against
existing repositories with no applied patches and HEAD !=
refs/heads/base, also do the update every time someone asks for the
name of refs/heads/base.
Signed-off-by: Karl Hasselström <redacted>
---
stgit/stack.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
@@ -366,6 +366,7 @@ class Series:returnnamesdefget_base_file(self):+self.__begin_stack_check()returnself.__base_filedefget_protected(self):
@@ -686,6 +687,7 @@ class Series:f=file(self.__unapplied_file,'w+')f.writelines([line+'\n'forlineinunapplied])f.close()+self.__begin_stack_check()defforward_patches(self,names):"""Try to fast-forward an array of patches.
I added your name on the copyright since this is a new file.
I did that too at first, but then I changed it back since I reckoned
more than 50% of the file was copy-pasted from elsewhere. But thanks.
:-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: Sam Vilain <hidden> Date: 2016-06-15 22:42:19
Karl Hasselström wrote:
quoted
quoted
I added your name on the copyright since this is a new file.
I did that too at first, but then I changed it back since I reckoned
more than 50% of the file was copy-pasted from elsewhere. But
thanks. :-)
By the way, it seems like my name got munged when you edited the
commit.
I have noticed this munging happening, when I am using a UTF-8 locale.
While we are talking about non-linear messing around with the commit
history, can I request a feature?
Currently, I have a patch stack where I want the top of one of the
patches to always be a particular revision. Consider the last revision
to be like a "difference" revision (ie "what's left" when re-organising
a patch set).
How about a "stg push --fudge-to c033171d..." command for this?
Sam.
On 19/02/06, Karl Hasselström [off-list ref] wrote:
By the way, it seems like my name got munged when you edited the
commit.
I fixed the escaping in the name_email* functions (I'll push it
tonight). It was adding a \ for every character it didn't know. It now
only escapes the quotes and back-slashes. This is needed when passing
the strings via the GIT_AUTHOR_* variables.
--
Catalin
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-20 17:20:47 +0000, Catalin Marinas wrote:
On 19/02/06, Karl Hasselström [off-list ref] wrote:
quoted
By the way, it seems like my name got munged when you edited the
commit.
I fixed the escaping in the name_email* functions (I'll push it
tonight). It was adding a \ for every character it didn't know. It
now only escapes the quotes and back-slashes. This is needed when
passing the strings via the GIT_AUTHOR_* variables.
It put curly braces around the name as well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
On 20/02/06, Karl Hasselström [off-list ref] wrote:
On 2006-02-20 17:20:47 +0000, Catalin Marinas wrote:
quoted
I fixed the escaping in the name_email* functions (I'll push it
tonight). It was adding a \ for every character it didn't know. It
now only escapes the quotes and back-slashes. This is needed when
passing the strings via the GIT_AUTHOR_* variables.
It put curly braces around the name as well.
It wasn't StGIT. Running "git log" on my machine only shows \'s and
some weird characters. Maybe it's your terminal showing braces.
--
Catalin
From: Karl Hasselström <hidden> Date: 2016-06-15 22:42:19
On 2006-02-20 22:49:22 +0000, Catalin Marinas wrote:
On 20/02/06, Karl Hasselström [off-list ref] wrote:
quoted
It put curly braces around the name as well.
It wasn't StGIT. Running "git log" on my machine only shows \'s and
some weird characters.
Those weird characters are the two bytes that make up the character
"ö" (o with two dots on top of it) in utf8. That's what the utf8
variant of my name looks like when displayed in latin1. :-/
Maybe it's your terminal showing braces.
You're right, they don't show when I use git-log, so I guess they
aren't really there after all. But they do show up in gitk.
Hopefully all this weirdness will go away with the backslashes. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle