From: Yann Dirson <ydirson@altern.org>
To: Pavel Roskin <proski@gnu.org>
Cc: Catalin Marinas <catalin.marinas@gmail.com>,
git <git@vger.kernel.org>, Charles Lever <cel@citi.umich.edu>
Subject: Re: StGIT: "stg new" vs "stg new --force"
Date: Thu, 19 Jan 2006 22:38:39 +0100 [thread overview]
Message-ID: <20060119213838.GA27397@nowhere.earth> (raw)
In-Reply-To: <1137631749.13853.22.camel@dv>
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/>
next prev parent reply other threads:[~2006-01-19 21:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-13 9:24 StGIT: "stg new" vs "stg new --force" Pavel Roskin
2006-01-13 9:34 ` Karl Hasselström
2006-01-16 8:18 ` Catalin Marinas
2006-01-17 17:01 ` Pavel Roskin
2006-01-17 21:57 ` Yann Dirson
2006-01-17 23:16 ` Pavel Roskin
2006-01-18 19:37 ` Yann Dirson
2006-01-19 0:49 ` Pavel Roskin
2006-01-19 21:38 ` Yann Dirson [this message]
2006-01-20 6:23 ` Pavel Roskin
2006-01-20 18:22 ` J. Bruce Fields
2006-01-24 5:30 ` Pavel Roskin
2006-01-24 17:54 ` J. Bruce Fields
2006-01-24 18:17 ` Pavel Roskin
2006-01-24 21:23 ` Catalin Marinas
2006-01-21 18:24 ` Catalin Marinas
2006-01-22 5:05 ` Pavel Roskin
2006-01-21 18:20 ` Catalin Marinas
2006-01-21 18:31 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060119213838.GA27397@nowhere.earth \
--to=ydirson@altern.org \
--cc=catalin.marinas@gmail.com \
--cc=cel@citi.umich.edu \
--cc=git@vger.kernel.org \
--cc=proski@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).