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

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.

On 2006-01-13 04:24:51 -0500, Pavel Roskin wrote:

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.

Hi Pavel,

On 13/01/06, Pavel Roskin <proski@gnu.org> wrote:

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.

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

Hello, Catalin!

On Mon, 2006-01-16 at 08:18 +0000, Catalin Marinas 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. In this case, indeed, you don't want the newly created patch to suck in all the changes in the local repository.

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.

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

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,

On Tue, 2006-01-17 at 22:57 +0100, Yann Dirson wrote:

Absolutely.

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.

On Tue, Jan 17, 2006 at 06:16:02PM -0500, Pavel Roskin wrote:

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,

On Wed, 2006-01-18 at 20:37 +0100, Yann Dirson wrote:

Definitely.  Hard cases should be handled by hand.

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.

On Wed, Jan 18, 2006 at 07:49:09PM -0500, Pavel Roskin wrote:

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

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 ?

On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:

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.

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.

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

On Fri, Jan 20, 2006 at 01:23:44AM -0500, Pavel Roskin 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....

--b.

On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields wrote:

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

On Tue, Jan 24, 2006 at 12:30:23AM -0500, Pavel Roskin wrote:

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.

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.

On Tue, 2006-01-24 at 12:54 -0500, J. Bruce Fields wrote:

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.

Put remaining changes to the repository.

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

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.

On 24/01/06, Pavel Roskin <proski@gnu.org> wrote:

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

On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:

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

Hello, Catalin!

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

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

On 17/01/06, Yann Dirson <ydirson@altern.org> wrote:

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

On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:

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.

--