as is can still point someone in the right
direction.)
From: Eric Rubin-Smith
Sent: Tuesday, 15 September 2015 01:38
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] merge after cherrypick plus edit does not identify GCA
as I would like
See
> The merge algorithm does *not* consider cherry-picks. It looks for
> the most recent common ancestor without taking cherry-picks into
> account.
Another popular version control tool whose name I won't mention (hint: rhymes
with "zit") behaves identically to fossil in this scenario. Is there
On 9/15/15, Eric Rubin-Smith wrote:
>
>> The merge algorithm does *not* consider cherry-picks. It looks for
>> the most recent common ancestor without taking cherry-picks into
>> account.
>
> Another popular version control tool whose name I won't mention (hint:
> rhymes with
a sideways question on this topic. Assume in my C editor I run
the code formatter operation which indents and parses certain
tokens for cosmetic, but not functional, changes in the file. By
parsing I mean operations such as adding/removing linefeeds
before/after a token such as a bracket or
On 9/14/15, Eric Rubin-Smith wrote:
> See the transcript below for gory details. The summary is:
>
> 1. create a new file on trunk and check it in.
> 2. edit the file and check in on a branch (let's call it "beta")
> 3. trunk decides it wants that particular change set from
> Merge is done by a classic 3-way diff. It looks at all the changes
> that occurred on the path from A to B and applies those same changes
> to C. (A in this case would be the most recent common ancestor of B
> and C).
>
> How would cherry-picks factor into this?
>
Sorry, maybe I'm confused.
Fossil knows nothing about syntax of any sort, so a merge must consider any
change as significant. Try reindenting a python script, where whitespace is
part of the syntax. Diff can be told to ignore changes in spacing, iirc. If
you switch from unix EOL to Windows EOL fossil will see the whole file
See the transcript below for gory details. The summary is:
1. create a new file on trunk and check it in.
2. edit the file and check in on a branch (let's call it "beta")
3. trunk decides it wants that particular change set from step (2), so
cherrypick it (assume in this example that other stuff
8 matches
Mail list logo