On Tue, 2006-01-24 at 12:54 -0500, J. Bruce Fields wrote:
quoted text
> 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.

quoted text
> > 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.

quoted text
>   Or on the
> next push or pop?

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

quoted text
>  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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html