If I have local changes that I haven't checked in, and the merge would
conflict with those changes, including by deleting my file, fossil
should say something like:
Hey, this merge will conflict with your uncommitted changes to:
* File X
* File Y
Commit your changes or use --force to merge
On Sun, Dec 12, 2010 at 06:57:56PM -0500, Richard Hipp wrote:
Suppose you have the trunk branch checked out and you have made changes to
file xyz.txt locally, but have not checked them in. Then you do a merge of
branch other-branch:
fossil merge other-branch
The file xyz.txt has
Hello,
In a related subject about merge, I think that fossil should give
more information in the merge marker lines in the files. I think that
it would be appropiate to explain, in each of the two versions of the
code, from which versions they come from or if they come from local
changes.
Local edits being lost seems the wrong thing to do, even if they are
recoverable with an undo action - undo doesn't always do what I expect,
which is probably user error, but since undo is only one level deep st
also seems that if they are not recovered immediately, they would be
lost forever.
Would that be equivalent to something like git stash?
For the same situation in git, I stash my uncommitted
local changes before merging in and then pop the stash
to resolve any merge conflicts.
-Kumar
On Tue, Dec 14, 2010 at 3:03 AM, Jeff Rogers dv...@diphi.com wrote:
Local edits being lost
Suppose you have the trunk branch checked out and you have made changes to
file xyz.txt locally, but have not checked them in. Then you do a merge of
branch other-branch:
fossil merge other-branch
The file xyz.txt has been deleted in other-branch. What should fossil's
response be? Should
On Sun, Dec 12, 2010 at 7:24 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
On Sun, Dec 12, 2010 at 06:57:56PM -0500, Richard Hipp wrote:
Suppose you have the trunk branch checked out and you have made changes
to
file xyz.txt locally, but have not checked them in. Then you do a
I would think if I merge a branch that deletes the file and I have local
changes the file would still exist on disk but would be treated like a
untracked file. Meaning, if I was to run fossil extras after the merge the file
would show up. Does this make sense?
On Dec 12, 2010, at 7:30 PM,
On Sun, Dec 12, 2010 at 8:04 PM, James Turner ja...@calminferno.net wrote:
I would think if I merge a branch that deletes the file and I have local
changes the file would still exist on disk but would be treated like a
untracked file. Meaning, if I was to run fossil extras after the merge the
On Sun, Dec 12, 2010 at 07:30:49PM -0500, Richard Hipp wrote:
On Sun, Dec 12, 2010 at 7:24 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Consider it a merge conflict.
You mean refuse to do the merge?
Yes, at least automatically.
Certainly a conflict warning will be issued, but
On Dec 12, 2010, at 8:15 PM, Richard Hipp wrote:
On Sun, Dec 12, 2010 at 8:04 PM, James Turner ja...@calminferno.net wrote:
I would think if I merge a branch that deletes the file and I have local
changes the file would still exist on disk but would be treated like a
untracked file.
11 matches
Mail list logo
