sending changesets from the middle of a git tree

Just to confirm a recent answer to questions on lkml ...

1) There is no way to send a particular changeset from the "middle" of a 
set from one tree to another, without exporting it as a patch or 
rebuilding a new git tree.   I have two changesets that, after testing 
last week, I now consider more important to send upstream than the few 
earlier and later changesets.   If I export those two changesets as 
patches, and send them on. presumably I lose the changset comments etc. 
and then when the upstream tree is merged back, it might look a little 
odd in the changeset history.

2) There is no way to update the comment field of a changeset after it 
goes in (e.g. to add a bugzilla bug number for a bug that was opened 
just after the fix went in).

3) There is no way to do a test commit of an individual changeset 
against a specified tree (to make sure it would still merge cleanly, 
automatically).

Are there easier ways to do any of these?

On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:

Just to confirm a recent answer to questions on lkml ...

1) There is no way to send a particular changeset from the "middle" of a 
set from one tree to another, without exporting it as a patch or 
rebuilding a new git tree.   I have two changesets that, after testing 
last week, I now consider more important to send upstream than the few 
earlier and later changesets.   If I export those two changesets as 
patches, and send them on. presumably I lose the changset comments etc. 
and then when the upstream tree is merged back, it might look a little 
odd in the changeset history.

You can keep most of the metadata you want with "git format-patch".

Extract the changes you need, mail them off.

When you later merge things back together, it should be a trivial merge,
hopefully.

2) There is no way to update the comment field of a changeset after it 
goes in (e.g. to add a bugzilla bug number for a bug that was opened 
just after the fix went in).

No, a commit is immutable.  You can use "git format-patch" to rebase things if
you need.  I prefer to use "git format-patch --mbox", edit what I need
to, then use git-applymbox to rebase it all against a clean tree.

3) There is no way to do a test commit of an individual changeset 
against a specified tree (to make sure it would still merge cleanly, 
automatically).

Not sure on this one - in this case, it almost sounds like you want the
feature set of StGit, and/or quilt.  (If "quilt push" succeeds, clearly
it still merges cleanly.)


-- 

Ryan Anderson
  sometimes Pug Majere

On Sat, 13 Aug 2005, Steve French wrote:

1) There is no way to send a particular changeset from the "middle" of a 
set from one tree to another, without exporting it as a patch or 
rebuilding a new git tree.

Correct.

If I export those two changesets as patches, and send them on.
presumably I lose the changset comments etc.

Well, you can export them with "git send-email" and you won't be losing 
any comments.

Alternatively, use "git cherry", which helps re-order the commits in your
tree. They'll be _new_ commits, but they'll have the contents moved over. 
Junio, maybe you want to talk about how you move patches from your "pu" 
branch to the real branches.

and then when the upstream tree is merged back, it might look a little
odd in the changeset history.

Well, you'll end up having the same change twice. It happens. Or if you 
just redo your tree as a separate branch, you can reorder things so that 
you don't have them twice at all.

2) There is no way to update the comment field of a changeset after it 
goes in (e.g. to add a bugzilla bug number for a bug that was opened 
just after the fix went in).

That's correct. Same things apply: you can move a patch over, and create a 
new one with a modified comment, but basically the _old_ commit will be 
immutable.

The good news is that it means that nobody else can change what you said 
or did either. 

3) There is no way to do a test commit of an individual changeset 
against a specified tree (to make sure it would still merge cleanly, 
automatically).

Oh, sure, that's certainly very possible, and the git cherry stuff even
helps you do it.  Or use "git-apply --check" to just see if a patch
applies and do your own scripts. 

		Linus

On Sat, 13 Aug 2005, Linus Torvalds wrote:

That's correct. Same things apply: you can move a patch over, and create a 
new one with a modified comment, but basically the _old_ commit will be 
immutable.

Let me clarify.

You can entirely _drop_ old branches, so commits may be immutable, but
nothing forces you to keep them. Of course, when you drop a commit, you'll 
always end up dropping all the commits that depended on it, and if you 
actually got somebody else to pull that commit you can't drop it from 
_their_ repository, but undoing things is not impossible.

For example, let's say that you've made a mess of things: you've committed
three commits "old->a->b->c", and you notice that "a" was broken, but you
want to save "b" and "c". What you can do is

	# Create a branch "broken" that is the current code
	# for reference
	git branch broken

	# Reset the main branch to three parents back: this 
	# effectively undoes the three top commits
	git reset HEAD^^^
	git checkout -f

	# Check the result visually to make sure you know what's
	# going on
	gitk --all

	# Re-apply the two top ones from "broken"
	#
	# First "parent of broken" (aka b):
	git-diff-tree -p broken^ | git-apply --index
	git commit --reedit=broken^

	# Then "top of broken" (aka c):
	git-diff-tree -p broken | git-apply --index
	git commit --reedit=broken

and you've now re-applied (and possibly edited the comments) the two
commits b/c, and commit "a" is basically gone (it still exists in the
"broken" branch, of course).

Finally, check out the end result again:

	# Look at the new commit history
	gitk --all

to see that everything looks sensible.

And then, you can just remove the broken branch if you decide you really 
don't want it:

	# remove 'broken' branch
	rm .git/refs/heads/broken

	# Prune old objects if you're really really sure
	git prune

And yeah, I'm sure there are other ways of doing this. And as usual, the 
above is totally untested, and I just wrote it down in this email, so if 
I've done something wrong, you'll have to figure it out on your own ;)

			Linus

On Sun, Aug 14, 2005 at 12:02:33AM -0400, Ryan Anderson wrote:

On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:

quoted

2) There is no way to update the comment field of a changeset after it 
goes in (e.g. to add a bugzilla bug number for a bug that was opened 
just after the fix went in).

No, a commit is immutable.  You can use "git format-patch" to rebase things if
you need.  I prefer to use "git format-patch --mbox", edit what I need
to, then use git-applymbox to rebase it all against a clean tree.

Note (and I should have said this at first), doing it this way gives you
the opportunity to combine a few changes if you want.

Use git-format-patch-script to pull out what you want, delete the diff
from the bottom of the file, manually diff what you need using
git-diff-script, and stick that back at the end of the file
git-format-patch-script created.

This seems to be the easiest way to clean up your change history.

-- 

Ryan Anderson
  sometimes Pug Majere