Re: sending changesets from the middle of a git tree

[Catalin Marinas <catalin.marinas@gmail.com>]

There are other ways to do these, explained in this thread. I will
only show the StGIT way, just choose which one suits you better.

Steve French <smfrench@austin.rr.com> 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.  I have two changesets that, after
> testing last week, I now consider more important to send upstream
> than the few earlier and later changesets.

With StGIT, you create a new patch ('stg new <name>'), modify and
commit the changes with 'stg refresh'. All the modifications to a
patch are stored as a single GIT commit. If you manage a (contributor)
tree with StGIT, you shouldn't commit changes directly with GIT but
use the StGIT commands instead. You end up with a stack of changesets
on top of the main tree.

You can send the changesets upstream with the 'stg mail' command or
export them with 'stg export'.

> 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.

Pulling the latest changes from the main tree will keep your changes
on top, much like git cherry/rebase, but StGIT does a diff3 merge
instead of simply generating and applying patch. This has the
advantage of detecting when a patch (changeset) was not fully merged
or was modifed. If the upstream merge was complete, StGIT shows your
patch as empty (since your patch no longer needs to change the
tree). Otherwise, you can either have some changes in the patch or
even be notified of a conflict (patch modified before being merged).

> 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).

'stg refresh --edit' lets you modify the patch text. Since the GIT
commits are immutable, a new commit is generated but the parent of the
new commit is the same as the parent of the old commit (making this
commit unaccessible). Being able to create your own DAG structure with
GIT is what made StGIT possible.

> 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).

With StGIT you can pop all the patches from the stack and only push
the one you want to test (the push/pop operations also allow patch
reordering). Note that the push operation is done with a three-way
merge and, if successful, the patch might have a sligthly different
form (different offsets for example, or even chunks removed if they
are already in the tree).

If the push fails, it means that it doesn't apply cleanly because it
depends on changes made by other patches in your series. You can undo
the push operation with 'stg push --undo'.

-- 
Catalin