Re: sending changesets from the middle of a git tree

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Aug 15, 2005, 09:27 UTC
Message-ID: <tnxiry77dok.fsf@arm.com>
In-Reply-To: <42FEBC16.9050309@austin.rr.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:

Show 5 quoted lines

> 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