All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Yann Dirson <ydirson@altern.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 19:49:09 -0500	[thread overview]
Message-ID: <1137631749.13853.22.camel@dv> (raw)
In-Reply-To: <20060118193717.GI32585@nowhere.earth>

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

  reply	other threads:[~2006-01-19  0:49 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 [this message]
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=1137631749.13853.22.camel@dv \
    --to=proski@gnu.org \
    --cc=catalin.marinas@gmail.com \
    --cc=cel@citi.umich.edu \
    --cc=git@vger.kernel.org \
    --cc=ydirson@altern.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.