I think that after a git-rebase or a fossil-merge, the content of the leaves
of all branches are the same.  The difference is that with git-rebase, you
have rewritten the history of the branch so that whereas in reality
development of the "topic" branch began with version E,

         A---B---C topic
        /
   D---E---F---G master


After git-rebase, it appears as if the development of topic began with
version G.

                 A'--B'--C' topic
                /
   D---E---F---G master

With a fossil-merge, you end up with a new version D which has the same
content as version C' in git:

         A---B---C---D topic
         /
    D---E---F---G master

But with fossil, the fact that you started development on version E is
preserved in the history.  (Note that in the ascii-art diagram above I am
not showing the merge from G to D, but that merge is shown on the
timeline-graph in an actual Fossil instance.)

Some people seem cool with the idea of rewriting the history of a project.
Others no so much.  Some commentators have suggested that "git rebase"
should be renamed to "git lie".  The whole idea does seem like something out
of 1984.  (Wasn't Winston Smith's job in that novel to do "rebasing" all
day?)  For me:  I need an unimpeachable audit trail for certain projects and
rebase is not consistent with that.


On Thu, Jun 24, 2010 at 9:20 AM, Michael Richter <ttmrich...@gmail.com>wrote:

> I'm not a git user, so I have no idea.
>
>
> On 24 June 2010 18:56, <altufa...@mail.com> wrote:
>
>> I'm not sure. Is there really no difference?
>>
>> - Altu
>>
>>
>>
>> -----Original Message-----
>> From: Michael Richter <ttmrich...@gmail.com>
>> To: fossil-users@lists.fossil-scm.org
>> Sent: Thu, Jun 24, 2010 4:23 pm
>> Subject: Re: [fossil-users] fossil rebase
>>
>>
>> What does this do that fossil merge trunk from my branch in
>> ttmrichter doesn't do?
>>
>>
>> On 24 June 2010 16:31,  <altufa...@mail.com> wrote:
>> Well, you have custom changes (A, B, C) in a branch and you want to
>> keep up with latest changes happening in trunk - at frequent intervals.
>>
>> What rebase does is it applies your changes A, B & C to new head (G)
>> with a knowledge of everything that has happened between E & G. If any
>> of A, B or C was pulled in to the trunk, that change will be removed
>> automatically.
>>
>>
>> - Altu
>>
>>
>> -----Original Message-----
>> From: Eric <e...@deptj.eu>
>>
>> To: fossil-users@lists.fossil-scm.org
>> Sent: Thu, Jun 24, 2010 12:00 pm
>> Subject: Re: [fossil-users] fossil rebase
>>
>>
>>
>> > Git rebase help has a very good graphic to explain what it does:>>
>> Assume the following history exists and the current branch is
>> "topic":>>           A---B---C topic>          />     D---E---F---G
>> master>> From this point, the result of either of the following
>> commands:>> git rebase master> git rebase master topic> would be:>>
>>                A'--B'--C' topic>                  />     D---E---F---G
>> master>> Here, git forgets versions A, B & C if they are not published
>> (tagged).> I agree we don't want fossil to forget anything.>> However,
>> if fossil can do following, that would be very helpful:>>
>> A---B---C topic>            />           /       A'--B'--C' (new name)>
>>           /       />     D---E---F---G trunk>> - Altu>But why would
>> anyone want to do
>> that?E._______________________________________________fossil-users
>> mailing
>>
>> listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi
>>
>>
>>
>> -bin/mailman/listinfo/fossil-users
>>
>> _______________________________________________
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>>
>>
>>
>> --
>> "Perhaps people don't believe this, but throughout all of the
>> discussions of entering China our focus has really been what's best for
>> the Chinese people. It's not been about our revenue or profit or
>> whatnot."
>> --Sergey Brin, demonstrating the emptiness of the "don't be evil"
>> mantra.
>>
>>
>> _______________________________________________fossil-users mailing
>> listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi
>> -bin/mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
>>
>> _______________________________________________
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions
> of entering China our focus has really been what's best for the Chinese
> people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
---------------------
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

Reply via email to