On Tue, Jan 17, 2006 at 12:01:40PM -0500, Pavel Roskin wrote:
quoted text
> Hello, Catalin!
> 
> On Mon, 2006-01-16 at 08:18 +0000, Catalin Marinas wrote:
> > On 13/01/06, Pavel Roskin <proski@gnu.org> wrote:
> > > 1) "stg new --force" becomes "stg new" and "stg new" becomes "stg new
> > > --empty", i.e. empty files can only be created with the "--empty"
> > > switch.
> > > 2) "stg new --force" becomes "stg record" or something.
> > > 3) "stg new --force" becomes "stg new --record" or something.
> > > 4) "stg new" works both with and without modified files.
> > 
> > Regarding (1), the newly created patch is empty anyway, you would need
> > to run 'refresh' to add the modified patches to it ('stg series -e'
> > would show the empty patches prefixed with a 0).
> 
> I was going to suggest that would be logical to run "stg refresh"
> implicitly if "stg new" is used on modified files.  But then I realized
> that it would be even better if future versions of StGIT allowed to
> refresh (i.e. add changes to) patches other that the current one.  In
> this case, indeed, you don't want the newly created patch to suck in all
> the changes in the local repository.

I commonly also feel the need to "stg refresh" only part of the
current changes.  Allowing to limit the files to be impacted by a
refresh could be a good addition.

It would even be useful sometimes to dispatch changes to a single file
into several patches.  When they are distinct enough to be in
different diff hunks, it is pretty easy to split an existing patch,
but it could also be useful to only refresh a patch with specific diff
hunks.  A possibility would be to add a filterdiff-like "-#<n>" flag,
in addition to the above-suggested "refresh <file>" (and possibly only
allow to specify a single file together with this flag).


Best regards,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html