Re: Some ideas for StGIT

From: Pavel Roskin <proski@gnu.org>
Date: Aug 6, 2007, 17:17 UTC
Message-ID: <1186420646.12895.3.camel@dv>
In-Reply-To: <b0943d9e0708060236x19674e4cjf04cec716ae6246c@mail.gmail.com>

On Mon, 2007-08-06 at 10:36 +0100, Catalin Marinas wrote:

Show 8 quoted lines

> > The main point in favor of quilt is that it allows to edit the patches
> > with the text editor.  One can pop all patches, edit them and push the
> > all back.
> 
> If this is the main feature they need, they probably don't need git at
> all and quilt would be enough. I was using quilt before starting StGIT
> but the main problem I had with plain patches approach was the
> conflict solving.

OK, I understand it wasn't a good idea to ask for improvement on behalf of others.

Show 6 quoted lines

> StGIT does a 'git-diff | git-apply' as a patch push optimization and
> we could even cache the diff but the current algorithm is that if
> git-apply fails, StGIT falls back to a three-way merge and even an
> interactive user merge (via xxdiff for example). I find the three-way
> merging (automatic or interactive) much more powerful than fuzzy patch
> application.

I agree.  I have no problem with what StGIT does internally.

> If we would allow patch editing, the 'stg push' algorithms wouldn't
> know when git-apply failed because the patch was edited or the base
> was changed. Falling back to the three-way merge would lose the edited
> patch. If one doesn't need three-way merging, quilt is good enough.

I suggest that StGIT saves the original patch and then does interdiff between the old and the new patch. The original patch is applied first just as it's applied now, and then the difference is applied on top of that.

Temporary files should be kept in case of failure.

> Other advantages of the three-way merging is the detection of full
> patches or hunks merged upstream (the former can also be achieved by
> testing the reverse-application of the patches).

I'm fully with you here.  Having git history can only be a good thing.

Show 5 quoted lines

> I don't usually edit patches during development, I prefer to edit the
> source files and review the diff. It happens many times to move hunks
> between patches but I usually towards the bottom patches in the stack
> (using stg export and emacs) and the three-way merging automatically
> removes the merged hunks from top patches.

What I normally need to edit is the comments. Editing the code is risky, although I may want to rename some badly named variable introduced by the patch.

Show 7 quoted lines

> > I don't suggest that StGIT gives up on the git-based storage, but this
> > mode of operation could be implemented in two ways.
> >
> > One is to have a command opposite to "export".  It would read the files
> > that "export" produces, replacing the existing patches.
> 
> As Yann said, we already have 'stg import --replace'.

Thanks!

Show 8 quoted lines

> > Another approach would be to reexamine the patch after "stg refresh -es"
> > and to apply it instead of the original patch.  If the patch doesn't
> > apply, the options would be to discard the edits or to re-launch the
> > editor.
> 
> That's an interesting idea but maybe we should have a separate command
> like --edit-full to edit the full patch + log (part of the
> functionality already available in import).

I hate to be in a situation when I want to edit something but cannot, because I didn't run some command before. What I like about StGIT is that it allows me to do things my way.

I don't know if I want to change the patch before I see it.

Show 5 quoted lines

> > Finally, it would be great to have TLS support in the mail command.
> > Mercurial has it, and looking at their mail.py, it doesn't seem to be
> > much work.
> 
> Indeed, the SMTP Python objects already provide support for TLS via starttls().

And hg provides a great example.

-- 
Regards,
Pavel Roskin