Sorry for the confusion.
By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m doing the
merge.
And, I’m merging the “check-in from the ... [other] branch” I mean the
check-in which is part of the other part.
I think I’m beginning to understand what’s going on. If I do a full
Here’s a merge conflict I thought should have been resolved automatically:
I have the trunk version from where the symbol RF_OUT is renamed to SRF_OUT in
the branch version. It has never been renamed to SRF_OUT in the trunk version
(yet).
When trying to merge (--cherrypick, actually) from
On Fri, Nov 13, 2015 at 4:20 PM, Tony Papadimitriou wrote:
> <<< BEGIN MERGE CONFLICT: local copy shown first <<<
> @?status RF_OUT,#?MsgOn,#?MsgOff,fWriteZ
> === COMMON ANCESTOR content follows
>
On Nov 13, 2015 9:15 AM, "Tony Papadimitriou" wrote:
>
> Sorry for the confusion.
> By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m
doing the merge.
> And, I’m merging the “check-in from the ... [other] branch” I mean the
check-in which is part of the other
On Fri, Nov 13, 2015 at 4:33 PM, Tony Papadimitriou wrote:
> The important thing is that the *common ancestor* with regards to this
> line of code is the local version, since it hasn’t changed in the trunk,
> only in the branch. So, I expected all (accumulated) changes in the
>
Yes, sorry, I didn’t mention that.
‘puts’ replaced ‘fWriteZ’ in the last (cherry-picked) check-in – not in the
same check-in as the label rename. But, I think it’s irrelevant.
The important thing is that the common ancestor with regards to this line of
code is the local version, since it
On Nov 13, 2015 8:20 AM, "Tony Papadimitriou" wrote:
>
> Here’s a merge conflict I thought should have been resolved automatically:
>
> I have the trunk version from where the symbol RF_OUT is renamed to
SRF_OUT in the branch version. It has never been renamed to SRF_OUT in the
On Fri, 13 Nov 2015 09:27:54 -0500
Richard Hipp wrote:
> https://twitter.com/bos31337/status/663954649922142208
>
I saw once this personnel instruction: http://i.imgur.com/3POtveC.jpg
But obviously (as always) the instructions does not agree with the real worlds.
:D
> --
I have to agree with your first four sentences.
Your prove-it-to-yourself example, however, is quite different from my case
where all changes happened in the same branch, and trunk was unaltered (with
respect to the lines in question).
Obviously, if the same line of code changes on both sides
How do I authenticate myself to the cgi-based repository when I'm trying
to push my changes back up? Here is what I'm doing:
fossil clone
fossil open
echo "file1" > file1
fossil add file1
fossil commit
At this point, the local commit is fine, but the autosync fails due to
lack of write
On 11/13/15, Angelo Bertolli wrote:
> How do I authenticate myself to the cgi-based repository when I'm trying
> to push my changes back up?
(1) Do your initial clone using your username/password:
fossil clone http://use...@www.repo.org/path/to/repo
The "userid@" part
If it would be helpful, I'd be glad to take a look at your repo, or a
fabricated repo that demonstrates the same issue. Without the actual
current state of the repo, it's hard to know what the exact problem is.
Hence my previous guesses.
I didn't write the merge code, but I once upon a time
The following Windows batch file will reproduce the condition I’m talking about
(f = fossil):
f new sample.fossil
f o sample.fossil
echo Hello > hello.txt
f add hello.txt
f com -m Initial
echo Hello, World > hello.txt
f com --branch other -m "Added World!"
echo Computer
https://twitter.com/bos31337/status/663954649922142208
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
14 matches
Mail list logo