Thus said Richard Hipp on Wed, 04 Jun 2014 13:48:48 -0400:
> No merge is perfect. Apparently you hit a bad case. But I do similar
> things all the time on actual source code and rarely have problems.
Ok, thanks. I just wanted to make sure I wasn't misunderstanding.
I can offer up the repositor
On Wed, Jun 4, 2014 at 1:42 PM, Andy Bradford
wrote:
> Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400:
>
> > The merge logic in Fossil recognizes when the same exact change is
> > merged more than once and avoids conflicts in that case. The Q-cards
> > are not necessary for this.
Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400:
> The merge logic in Fossil recognizes when the same exact change is
> merged more than once and avoids conflicts in that case. The Q-cards
> are not necessary for this.
What am I doing wrong then? In this case, I did a cherr
On Wed, Jun 4, 2014 at 12:07 AM, Andy Bradford
wrote:
> Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600:
>
> > Does the Q-card here not imply any relation with c14a4a93d5a3 which will
> > be picked up in trunk?
>
> It seems I did not understand this very well:
>
> A Q-card is simi
Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600:
> Does the Q-card here not imply any relation with c14a4a93d5a3 which will
> be picked up in trunk?
It seems I did not understand this very well:
A Q-card is similar to a P-card in that it defines a predecessor
to the current
Hello,
While experimenting with --cherrypick I stumbled upon this situation:
$ fossil merge trunk
cannot find a common ancestor between the current checkout and trunk
$ f stat | grep checkout
checkout: 738e72e3d9cfe5568c94940c09ada1b78341ac68 2014-06-04 03:48:59 UTC
$ fossil artifact 738e72e3
6 matches
Mail list logo
