Re: [StGit PATCH 5/6] Refresh the main stg man page

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

2008/10/5 Karl Hasselström <kha@treskal.com>:
> Update the text to reflect what's happened in StGit in the last few
> releases. Also, consistently capitalize the names "Git" and "StGit".

I need to change the websites as well (BTW, I gave you admin rights on
the gna.org project page).

> --- a/Documentation/stg.txt
> +++ b/Documentation/stg.txt
[...]
> +  * After making changes to the worktree, you can incorporate the
> +    changes into an existing patch; this is called 'refreshing'. You
> +    may refresh any patch, not just the topmost one.

I wouldn't advertise the refreshing of "any" patch as it doesn't
always work (it actually fails in a lot of cases). Or at least we
could mention that there are some restrictions.

> +  * You can easily 'rebase' your patch stack on top of any other Git
> +    branch.

It might be better with something like "on top of a different Git
commit". The first thought when reading the above is that you can move
the patch stack to a different Git branch easily, which is not the
case (you need to cherry-pick the patches).

> +  * The patch stack is just some extra metadata attached to regular
> +    Git commits, so you can continue to use Git tools along with
> +    StGit.

Again, this is with some restrictions (or there aren't any with the
new infrastructure?).

> +  Tracking changes from a remote branch, while maintaining local
> +  modifications against that branch, possibly with the intent of
> +  sending some patches upstream. You can modify your patch stack as
> +  much as you want, and when your patches are finally accepted
> +  upstream, the permanent recorded Git history will contain just the
> +  final sequence of patches, and not the messy sequence of edits that
> +  produced them.

Maybe we could mention that the local history is also clean, not only
the upstream tree (though you mention it later in a different hunk).

-- 
Catalin