cg-seek messed me up

cg-seek messed me up

[Zack Brown]

Hi folks,

I'm not positive, but I *think* I shot myself in the foot by doing a cg-seek
when there were uncommitted changes in my working file set. The patching process
created duplicate areas in the files, while losing other areas and giving
patch rejects. Before I figured out the problem, I wasn't even able to seek to a
known state because of this, so I ended up having to recreate the files as best
as I could from the mess I was left with in the working directory. I realize I
could have gotten a clean tree by cloning, but this didn't occur to me at the
time. It seemed like the whole repository was just corrupt.

I think I recovered everything, and I know it was my own mistake, but it
seems like this will be a common blunder by users. Maybe cg-seek should
first do a comparison between the working tree and the most recent known
state. If the two differ, it should exit with an error.

Be well,
Zack

-- 
Zack Brown

Re: cg-seek messed me up

[Thomas Glanzmann]

Hello,
this is exactly why I don't use it at the moment. My own frontend does
before every pull/push/merge/commit a 'look for dirty files and look for
uncommited deltas'.

	Thomas

Re: cg-seek messed me up

[randy_dunlap]

On Tue, 31 May 2005 16:45:07 +0200 Thomas Glanzmann wrote:

| Hello,
| this is exactly why I don't use it at the moment. My own frontend does
| before every pull/push/merge/commit a 'look for dirty files and look for
| uncommited deltas'.

I don't recall where your frontend is.
Can you (re)post a pointer to it?

Thanks,
---
~Randy

Re: cg-seek messed me up

[Petr Baudis]

Dear diary, on Tue, May 31, 2005 at 04:33:18PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Hi folks,

Hi,

> I'm not positive, but I *think* I shot myself in the foot by doing a cg-seek
> when there were uncommitted changes in my working file set. The patching process
> created duplicate areas in the files, while losing other areas and giving
> patch rejects. Before I figured out the problem, I wasn't even able to seek to a
> known state because of this, so I ended up having to recreate the files as best
> as I could from the mess I was left with in the working directory. I realize I
> could have gotten a clean tree by cloning, but this didn't occur to me at the
> time. It seemed like the whole repository was just corrupt.
> 
> I think I recovered everything, and I know it was my own mistake, but it
> seems like this will be a common blunder by users. Maybe cg-seek should
> first do a comparison between the working tree and the most recent known
> state. If the two differ, it should exit with an error.

I've rewritten cg-seek to use the magical tree_timewarp function. So
what it will do now is that it will save the local changes, then just
overwrite the tree with the seeked-to target and then it will reapply
the local changes. This should give much better (although still far from
perfect) results and reduce the inconsistencies popping up.

Anyway, anytime you are in trouble, cg-cancel is the way out! ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor