StGIT: "stg new" vs "stg new --force"

StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

Hello, Catalin!

Maybe I don't understand something in StGIT, but it seems strange that
"stg new" creates empty patch by default and requires "--force" to
create a non-empty patch.

It's much easier to give a patch a name once I know what it does.  Most
times I don't even intend to make a patch.  Suppose, I compile
something, then I find that some quick hack is needed to compile, then
the hack becomes a reasonable general solution.  When does it make sense
to run "stg new"?  Obviously, at the point when I know the patch is good
enough to be kept and sent upstream.  It happens after I change some
files, not before.

It's actually very rare that I decide to fix something like "bug #42
from the tracker" before having changed a single line.  It's also rare
that I follow through without getting distracted or realizing that I'm
fixing some other bug instead.

Also, "--force" is a strong word for a switch.  It's normally used for
options that could trigger information loss or unintended consequences
that are hard to undo.  Telling StGIT to record my changes hardly
qualifies as anything dangerous.

I know of "stg rename", but I don't want to be forced to name a patch
before it's ready.

Possible solutions:

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.

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[Karl Hasselström]

On 2006-01-13 04:24:51 -0500, Pavel Roskin 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.

I agree with Pavel. I like option 4 the most, and 3 the least; since
creating a new patch from existing edits is more common (for me) than
creating an empty patch, it's awkward to make that command much
longer.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: StGIT: "stg new" vs "stg new --force"

[Catalin Marinas]

Hi Pavel,

On 13/01/06, Pavel Roskin <proski@gnu.org> wrote:
> Maybe I don't understand something in StGIT, but it seems strange that
> "stg new" creates empty patch by default and requires "--force" to
> create a non-empty patch.

The 'new' command would fail to create a new patch if there are
changes in the tree.

I also find myself using the '--force' option most of the time. Even
when I create a an empty patch, I use to run 'status' before. The
current implementation is closer to Quilt where, AFAIK, you first
create a new patch and use 'add' for every modified file. Since 'add'
has a different meaning in StGIT, it might also make sense to remove
the '--force' option.

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

Anyway, I would also prefer option 4. If there are no objections, I'll
modify StGIT accordingly. It would also be useful to have a wiki page
about StGIT vs. Quilt to show the main differences.

--
Catalin

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

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.

> Anyway, I would also prefer option 4. If there are no objections, I'll
> modify StGIT accordingly. It would also be useful to have a wiki page
> about StGIT vs. Quilt to show the main differences.

That would be great!

I'm trying to make StGIT my primary development tool, and I think it has
a great potential the could be realized if StGIT is freed from the need
to emulate older tools.

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[Yann Dirson]

On Tue, Jan 17, 2006 at 12:01:40PM -0500, Pavel Roskin wrote:
> 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/>

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

On Tue, 2006-01-17 at 22:57 +0100, Yann Dirson wrote:
> 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.

Absolutely.

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

I think if would be better to improve "stg fold" to work on arbitrary
patches.  This way, you prepare the patch in the editor (which would not
be harder than finding hunk numbers) and fold it into the patch of your
choice.  stg should check that the stack remains valid, possibly doing
trivial adjustments to the higher patches.  The current tree should not
be impacted.

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[Yann Dirson]

On Tue, Jan 17, 2006 at 06:16:02PM -0500, Pavel Roskin wrote:
> > 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).
> 
> I think if would be better to improve "stg fold" to work on arbitrary
> patches.  This way, you prepare the patch in the editor (which would not
> be harder than finding hunk numbers) and fold it into the patch of your
> choice.  stg should check that the stack remains valid, possibly doing
> trivial adjustments to the higher patches.  The current tree should not
> be impacted.

This sounds like a good idea as well (and I would use it on a near
daily basis as well ;).  Obviously such a request can also fail,
eg. when requesting to fold a change into a patch, where a subsequent
patch modifies the same lines.

But it would not be a replacement to selecting changes with a
granularity finer than file-level, which is what I wanted to suggest.

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

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

On Wed, 2006-01-18 at 20:37 +0100, Yann Dirson wrote:
> > > 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).
> > 
> > I think if would be better to improve "stg fold" to work on arbitrary
> > patches.  This way, you prepare the patch in the editor (which would not
> > be harder than finding hunk numbers) and fold it into the patch of your
> > choice.  stg should check that the stack remains valid, possibly doing
> > trivial adjustments to the higher patches.  The current tree should not
> > be impacted.
> 
> This sounds like a good idea as well (and I would use it on a near
> daily basis as well ;).  Obviously such a request can also fail,
> eg. when requesting to fold a change into a patch, where a subsequent
> patch modifies the same lines.

Definitely.  Hard cases should be handled by hand.

> But it would not be a replacement to selecting changes with a
> granularity finer than file-level, which is what I wanted to suggest.

Why?  Maybe you got confused by two meanings of the word "patch"?  I
think StGIT should use some other term, e.g. changeset.  I meant that
the diff file (e.g. made by "stg diff") could be edited and folded into
one of the StGIT patches (changesets).  Unless you want non-interactive
separation of the hunks, using an editor should be a reasonable
approach.

I believe StGIT should be primarily designed to be used interactively.
Your approach looks like a usability disaster to me.  The user is
supposed to find numbers of the hunks, although s/he is working on the
whole file (since it's "stg refresh").

My approach suggests that the user work with the diff from the
beginning, and separates the changes by looking at them.

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[Yann Dirson]

On Wed, Jan 18, 2006 at 07:49:09PM -0500, Pavel Roskin wrote:
> > But it would not be a replacement to selecting changes with a
> > granularity finer than file-level, which is what I wanted to suggest.
> 
> Why?  Maybe you got confused by two meanings of the word "patch"?  I
> think StGIT should use some other term, e.g. changeset.  I meant that
> the diff file (e.g. made by "stg diff") could be edited and folded into
> one of the StGIT patches (changesets).  Unless you want non-interactive
> separation of the hunks, using an editor should be a reasonable
> approach.

> My approach suggests that the user work with the diff from the
> beginning, and separates the changes by looking at them.

Oh, I think I now see what you meant.  I'm not sure it would be a good
idea to let the user edit the diff, although running an editor on it
is not much different from feeding it through filterdiff, or a
even through a graphical equivalent allowing to point at the hunks.


> I believe StGIT should be primarily designed to be used interactively.

I tend to disagree.  3rd-party apps like qgit should be able to let
the user do the selection, and tell the command-line tool what they
want to act upon.  It may be useful as well if stg gains
interactivity, but should not become the only way to work with it
(unix way of life).


> Your approach looks like a usability disaster to me.  The user is
> supposed to find numbers of the hunks, although s/he is working on the
> whole file (since it's "stg refresh").

That's what I'm currently doing to feed the hunk numbers to
filterdiff.  Any improvement in the process would be welcomed :)


Maybe we could have a "fold" or "refresh" variant that takes its
output from the output of "stg diff" (or any arbitrary diff on stdin,
to be friendly with GUI wrappers) filtered by an arbitrary command.
That command could be "cat" to get the current "refresh" behaviour, or
an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
whatever clever filter one would want to use.

Does it sound better ?
-- 
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/>

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:
> > I believe StGIT should be primarily designed to be used interactively.
> 
> I tend to disagree.  3rd-party apps like qgit should be able to let
> the user do the selection, and tell the command-line tool what they
> want to act upon.  It may be useful as well if stg gains
> interactivity, but should not become the only way to work with it
> (unix way of life).

In this particular case, the GUI frontend should be able to supply much
more data than the hunk numbers.  It would be much safer.

I didn't mean to say that StGIT shouldn't have any options for
non-interactive processing.  I meant that whenever adding a feature, we
should try to make it immediately useful without any frontends or
additional software.

> Maybe we could have a "fold" or "refresh" variant that takes its
> output from the output of "stg diff" (or any arbitrary diff on stdin,
> to be friendly with GUI wrappers) filtered by an arbitrary command.

That would be "fold".  "refresh" like is saying - this patch should
produce this file.  I actually tend to think now that deep refresh would
be confusing and dangerous if there is another patch closer in the stack
working with the same file, even in a separate part of it.  stg would
either report conflict with the higher patches use the file with the
higher patches reverted, and neither sounds good to me.

Deep fold of the local changes would be much easier, since no other
patch should have them.

> That command could be "cat" to get the current "refresh" behaviour, or
> an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
> whatever clever filter one would want to use.
> 
> Does it sound better ?

Yes.  The first step would be to fix "stg refresh --edit --showpatch" to
actually respect edits made to the patch.

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[J. Bruce Fields]

On Fri, Jan 20, 2006 at 01:23:44AM -0500, Pavel Roskin wrote:
> On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:
> > That command could be "cat" to get the current "refresh" behaviour, or
> > an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
> > whatever clever filter one would want to use.
> > 
> > Does it sound better ?
> 
> Yes.  The first step would be to fix "stg refresh --edit --showpatch" to
> actually respect edits made to the patch.

I tend to use stg refresh -es as a quick (well, not quite as quick as
I'd like) way to look at the current patch.  Often I leave it up while
I'm working (editing the patched files).  So if exiting from stg refresh
-es suddenly started overwriting my working files, I'd be very
unhappy....

--b.

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:
> I tend to use stg refresh -es as a quick (well, not quite as quick as
> I'd like) way to look at the current patch.  Often I leave it up while
> I'm working (editing the patched files).  So if exiting from stg refresh
> -es suddenly started overwriting my working files, I'd be very
> unhappy....

If I understand correctly, "stg refresh" only modifies the repository,
not the files in the local directory.  This shouldn't change.

It's only having two instances of "stg refresh -es" that would be a
problem if conflicting edits are made in both editors.  The answer to
that is "don't do it".

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[J. Bruce Fields]

On Tue, Jan 24, 2006 at 12:30:23AM -0500, Pavel Roskin wrote:
> On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:
> > I tend to use stg refresh -es as a quick (well, not quite as quick as
> > I'd like) way to look at the current patch.  Often I leave it up while
> > I'm working (editing the patched files).  So if exiting from stg refresh
> > -es suddenly started overwriting my working files, I'd be very
> > unhappy....
> 
> If I understand correctly, "stg refresh" only modifies the repository,
> not the files in the local directory.

Well, yeah, but the reason that makes sense is that it's modifying the
repository to bring it up to date with the working directory.

> This shouldn't change.

So after you hand-edit the diff and exit "stg refresh -es", the top of
the current patch will no longer agree with the state of the working
directory.  What are you going to do on the next refresh?  Or on the
next push or pop?  This seems a little confusing.

--b.

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

On Tue, 2006-01-24 at 12:54 -0500, J. Bruce Fields wrote:
> On Tue, Jan 24, 2006 at 12:30:23AM -0500, Pavel Roskin wrote:
> > On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:
> > > I tend to use stg refresh -es as a quick (well, not quite as quick as
> > > I'd like) way to look at the current patch.  Often I leave it up while
> > > I'm working (editing the patched files).  So if exiting from stg refresh
> > > -es suddenly started overwriting my working files, I'd be very
> > > unhappy....
> > 
> > If I understand correctly, "stg refresh" only modifies the repository,
> > not the files in the local directory.
> 
> Well, yeah, but the reason that makes sense is that it's modifying the
> repository to bring it up to date with the working directory.

Yes.  As it stands now, the update is made using the local state after
editing.  If the patch becomes editable, the update will use the local
state before editing.  It would still fit the original semantic as you
described it.

> > This shouldn't change.
> 
> So after you hand-edit the diff and exit "stg refresh -es", the top of
> the current patch will no longer agree with the state of the working
> directory.  What are you going to do on the next refresh?

Put remaining changes to the repository.

>   Or on the
> next push or pop?

Right now - protest loudly about local changes.  In the future - proceed
cautiously if there are no conflicts.

>  This seems a little confusing.

Try removing the whole repository while "stg refresh" is running.  THAT
would be confusing :-)

Seriously, it would be nice to have an editor that would allow to edit
the patch and see the resulting file and vice versa.  Maybe emacs could
be hacked to do it.

-- 
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[Catalin Marinas]

On 24/01/06, Pavel Roskin <proski@gnu.org> wrote:
> Seriously, it would be nice to have an editor that would allow to edit
> the patch and see the resulting file and vice versa.  Maybe emacs could
> be hacked to do it.

I think emacs has some basic support via ediff-merge or smerge but
it's difficult to integrate it with StGIT. Refreshing a patch with
StGIT means updating the GIT index files with the latest changes in
the working directory, save the index and create a commit object
pointing to it.

--
Catalin

Re: StGIT: "stg new" vs "stg new --force"

[Catalin Marinas]

On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:
> I think if would be better to improve "stg fold" to work on arbitrary
> patches.  This way, you prepare the patch in the editor (which would not
> be harder than finding hunk numbers) and fold it into the patch of your
> choice.  stg should check that the stack remains valid, possibly doing
> trivial adjustments to the higher patches.  The current tree should not
> be impacted.

Note that 'stg fold' uses git-apply-patch which doesn't take fuzzy
patches (a feature I began to like actually). Modifying the patch in
an editor might create some problems with applying.

--
Catalin

Re: StGIT: "stg new" vs "stg new --force"

[Pavel Roskin]

Hello, Catalin!

Quoting Catalin Marinas <catalin.marinas@gmail.com>:

> On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:
> > I think if would be better to improve "stg fold" to work on arbitrary
> > patches.  This way, you prepare the patch in the editor (which would not
> > be harder than finding hunk numbers) and fold it into the patch of your
> > choice.  stg should check that the stack remains valid, possibly doing
> > trivial adjustments to the higher patches.  The current tree should not
> > be impacted.
>
> Note that 'stg fold' uses git-apply-patch which doesn't take fuzzy
> patches (a feature I began to like actually). Modifying the patch in
> an editor might create some problems with applying.

Actually, the safest way would be to keep the original patch as presented to the
user.  Then the new patch would be "subtracted" from the original patch (using
e.g. interdiff from diff-utils).  The the difference would be "added" to the
current version of the patch.  Changes to "binary files differ" and similar
line should be ignored.  This way, changes to binary files are preserved.

For additional safety (and at expense or concurrency), it could be required that
 the patch is unchanged since the editor was launched.  Editors tend to run for
a long time compared to non-interactive utilities.

Fuzziness should be tolerated to a point.  Removing hunks could mean that the
line numbers would be slightly off.  If needed, the patch should be applied to
a temporary copy and regenerated from it.

--
Regards,
Pavel Roskin

Re: StGIT: "stg new" vs "stg new --force"

[Catalin Marinas]

On 17/01/06, Yann Dirson <ydirson@altern.org> wrote:
> 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).

Limiting the refresh to a set of file wouldn't be hard but doing it
per hunk it's a bit more complicated because StGIT only handles the
changes to the current tree over to GIT so that a new commit object is
created. It doesn't control the individual hunks.

What I usually do is create a dummy patch from the current changes,
pop it from the stack and only apply parts of it using emacs. Pushing
the dummy patch back would also show what changes were left to merge
in a proper patch.

--
Catalin

Re: StGIT: "stg new" vs "stg new --force"

[Catalin Marinas]

On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:
> 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.

I think that would be useful but not easy to implement. StGIT was
designed so that all operations happen on the top patch. The current
tree changes depend on the top patch and refreshing a different patch
with those changes would involve a three-way merge operation. This
merging can generate conflicts which are not relevant to the top tree
and they might even destroy the changes (depending on the merge
options).

The way I work is, again, through a dummy patch which can be folded
into the patch I want. This way I am sure that I still have the
changes in the dummy patch if I'm not happy with the merge. Maybe all
these could be done transparently and automatically remove the dummy
patch if conflicts exist.

--