Re: Problem with cg-merge
- From
Jonas Fonseca <fonseca@diku.dk>
- Date
- May 29, 2005, 22:58 UTC
- Message-ID
- <20050529225857.GA10715@diku.dk>
- In-Reply-To
- <20050529224042.GV1036@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> wrote Mon, May 30, 2005:
Show 20 quoted lines
> Dear diary, on Sun, May 29, 2005 at 11:15:24PM CEST, I got a letter > where Jonas Fonseca <fonseca@diku.dk> told me that... > > There is another problem I've noticed in the work on the cogito > > manpages. To make it easier to update the ``external'' patch I maintain > > I have added the files Documentation/make-cg-asciidoc and > > Documentation/make-cogito-asciidoc but not actually committed them. > > That way cg-diff will include them (diffed against /dev/null) which I > > like very much. However, when I cg-update from my local cogito origin > > cg-merge will fast-forward using cg-diff which results in rejects when > > patching the local changes due to the files already existing. > > > > One possibility would be to revert all local changes with the patch > > generated by cg-diff since most of them will be overwritten anyway. > > This would remove uncommitted added files but it would probably require > > use of the GIT metadata to get the fast-forwarding right with modes > > intact. > > I'm confused. Are you suggesting that we just throw away any local > changes when updating? That sounds horrible - it's something the user > has full right not to expect and I'd be very careful about it.
Forget what I suggested. The current way to cg-diff then update the tree and apply the local changes on top of that does handled locally added but uncommited files.
> In the longer term we shouldn't muck with diff | patch but instead do a > three-way merge on the local changes too.
Yes, that sounds nice.
-- Jonas Fonseca