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: Wed, 18 Jan 2006 20:37:17 +0100 [thread overview]
Message-ID: <20060118193717.GI32585@nowhere.earth> (raw)
In-Reply-To: <1137539762.12454.11.camel@dv>
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/>
next prev parent reply other threads:[~2006-01-18 19:34 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 [this message]
2006-01-19 0:49 ` Pavel Roskin
2006-01-19 21:38 ` Yann Dirson
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=20060118193717.GI32585@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.