From: Pavel Roskin <proski@gnu.org>
Date: Tue, 24 Jan 2006 18:17:51 GMT
Subject: Re: StGIT: "stg new" vs "stg new --force"
Message-ID: <1138126671.24415.28.camel@dv>
In-Reply-To: <20060124175443.GA29670@fieldses.org>

On Tue, 2006-01-24 at 12:54 -0500, J. Bruce Fields wrote:
> On Tue, Jan 24, 2006 at 12:30:23AM -0500, Pavel Roskin wrote:
> > On Fri, 2006-01-20 at 13:22 -0500, J. Bruce Fields 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....
> > 
> > If I understand correctly, "stg refresh" only modifies the repository,
> > not the files in the local directory.
> 
> 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.

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.

> > This shouldn't change.
> 
> 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?

Put remaining changes to the repository.

>   Or on the
> next push or pop?

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

>  This seems a little confusing.

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.

-- 
Regards,
Pavel Roskin