Re: StGIT: "stg new" vs "stg new --force"

From: Pavel Roskin <proski@gnu.org>
Date: Jan 24, 2006, 18:17 UTC
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:

Show 13 quoted lines

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

Show 5 quoted lines

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