Re: [fossil-users] fossil rebase
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 wrote: > I'm not a git user, so I have no idea. > > > On 24 June 2010 18:56, wrote: > >> I'm not sure. Is there really no difference? >> >> - Altu >> >> >> >> -Original Message----- >> From: Michael Richter >> 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, 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 >> >> 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/mai
Re: [fossil-users] fossil rebase
> I'm not sure. Is there really no difference? > > - Altu > > I was going to mention the merge too - I think that the resulting leaf would be the same, but the tree would not have been re-arranged. You **do not** change history. The principle is the same as in accounting, where you should not erase an erroneous entry, you should reverse it out. But then I tend to think in terms of Software Configuration Management, not source control. Regards, Eric > > -Original Message- > From: Michael Richter > 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, 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 > > 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 > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > 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
Re: [fossil-users] fossil rebase
I'm not a git user, so I have no idea. On 24 June 2010 18:56, wrote: > I'm not sure. Is there really no difference? > > - Altu > > > > -Original Message- > From: Michael Richter > 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, 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 > > 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 > > ___ > 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
Re: [fossil-users] fossil rebase
I'm not sure. Is there really no difference? - Altu -Original Message- From: Michael Richter 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, 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 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
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, 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 > 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 list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil rebase
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 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
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 list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
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 -Original Message- From: Richard Hipp To: fossil-users@lists.fossil-scm.org Sent: Wed, Jun 23, 2010 4:44 pm Subject: Re: [fossil-users] fossil rebase On Wed, Jun 23, 2010 at 3:42 AM, wrote: Well, my understanding of rebase has changed since then, due to the same problem we faced. Git 'forgets' unpublished versions when doing rebase (but it need not - I may still be wrong here). I'm sure if fossil implements rebase, it will not forget old versions. What I'm interested in is the 'feature' of rebase where it can re-apply changes to a new a new head. The result may be in a new branch. You cannot change history in Fossil, except you can correct typos in check-in comments and move a check-in into a new branch. But even those changes are recorded so that you can see them in a history of the repository. The inability to rewrite history is an important and deliberate feature - not a limitation or bug. If you want nice clean changes in your main tree, you can do most of your development work in a branch (call it "experimental" for example) and then periodically merge the experimental changes into the trunk. We do that a lot on SQLite. We strive to make sure that every check-in on trunk compiles and works, and so intermediate check-ins used for sharing or as works in progress are put on branches and are not moved onto the trunk until they are ready. That way, we can "bisect" on the trunk and all our historical trunk versions will actually compile and work. And, we can look at the merge diff to see an aggregate difference for some major change. Sometimes a check-in or two will go onto the trunk (because that is default action) but then we will realize that those check-ins should have been on a development branch. This is easy to fix by changing the branch of those check-ins. Sometimes a check-in occurs that we decide later to abandon. This can be done by moving that check-in into a branch that we typically call "mistake". - Altu -Original Message- From: Eric To: fossil-users@lists.fossil-scm.org Sent: Wed, Jun 23, 2010 12:27 pm Subject: Re: [fossil-users] fossil rebase > Hi,>> Is there a rebase feature in fossil that is similar to git rebase? If> not, is it planned?>> - AltuAnd what is different sincehttp://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg017 89.html?Eric___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 -- - D. Richard Hipp d...@sqlite.org ___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
Re: [fossil-users] fossil rebase
Thanks, I liked the description of your workflow. You should put it on the website. S. On Wednesday, June 23, 2010, Richard Hipp wrote: > > > On Wed, Jun 23, 2010 at 3:42 AM, wrote: > > Well, my understanding of rebase has changed since then, due to the > same problem we faced. Git 'forgets' unpublished versions when doing > rebase (but it need not - I may still be wrong here). I'm sure if > fossil implements rebase, it will not forget old versions. > > What I'm interested in is the 'feature' of rebase where it can re-apply > changes to a new a new head. The result may be in a new branch. > > > You cannot change history in Fossil, except you can correct typos in check-in > comments and move a check-in into a new branch. But even those changes are > recorded so that you can see them in a history of the repository. The > inability to rewrite history is an important and deliberate feature - not a > limitation or bug. > > If you want nice clean changes in your main tree, you can do most of your > development work in a branch (call it "experimental" for example) and then > periodically merge the experimental changes into the trunk. We do that a lot > on SQLite. We strive to make sure that every check-in on trunk compiles and > works, and so intermediate check-ins used for sharing or as works in progress > are put on branches and are not moved onto the trunk until they are ready. > That way, we can "bisect" on the trunk and all our historical trunk versions > will actually compile and work. And, we can look at the merge diff to see an > aggregate difference for some major change. > > Sometimes a check-in or two will go onto the trunk (because that is default > action) but then we will realize that those check-ins should have been on a > development branch. This is easy to fix by changing the branch of those > check-ins. > > Sometimes a check-in occurs that we decide later to abandon. This can be > done by moving that check-in into a branch that we typically call "mistake". > > > > > - Altu > > > -Original Message- > From: Eric > To: fossil-users@lists.fossil-scm.org > Sent: Wed, Jun 23, 2010 12:27 pm > Subject: Re: [fossil-users] fossil rebase > > >> Hi,>> Is there a rebase feature in fossil that is similar to git > rebase? If> not, is it planned?>> - AltuAnd what is different > sincehttp://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg017 > 89.html?Eric___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 > > > -- > - > D. Richard Hipp > d...@sqlite.org > -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil rebase
On Wed, Jun 23, 2010 at 3:42 AM, wrote: > Well, my understanding of rebase has changed since then, due to the > same problem we faced. Git 'forgets' unpublished versions when doing > rebase (but it need not - I may still be wrong here). I'm sure if > fossil implements rebase, it will not forget old versions. > > What I'm interested in is the 'feature' of rebase where it can re-apply > changes to a new a new head. The result may be in a new branch. > You cannot change history in Fossil, except you can correct typos in check-in comments and move a check-in into a new branch. But even those changes are recorded so that you can see them in a history of the repository. The inability to rewrite history is an important and deliberate feature - not a limitation or bug. If you want nice clean changes in your main tree, you can do most of your development work in a branch (call it "experimental" for example) and then periodically merge the experimental changes into the trunk. We do that a lot on SQLite. We strive to make sure that every check-in on trunk compiles and works, and so intermediate check-ins used for sharing or as works in progress are put on branches and are not moved onto the trunk until they are ready. That way, we can "bisect" on the trunk and all our historical trunk versions will actually compile and work. And, we can look at the merge diff to see an aggregate difference for some major change. Sometimes a check-in or two will go onto the trunk (because that is default action) but then we will realize that those check-ins should have been on a development branch. This is easy to fix by changing the branch of those check-ins. Sometimes a check-in occurs that we decide later to abandon. This can be done by moving that check-in into a branch that we typically call "mistake". > > - Altu > > > -Original Message- > From: Eric > To: fossil-users@lists.fossil-scm.org > Sent: Wed, Jun 23, 2010 12:27 pm > Subject: Re: [fossil-users] fossil rebase > > > > Hi,>> Is there a rebase feature in fossil that is similar to git > rebase? If> not, is it planned?>> - AltuAnd what is different > sincehttp://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg017 > 89.html?Eric___fossil-users<http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg017%0A89.html?Eric___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 > -- - 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
Re: [fossil-users] fossil rebase
Well, my understanding of rebase has changed since then, due to the same problem we faced. Git 'forgets' unpublished versions when doing rebase (but it need not - I may still be wrong here). I'm sure if fossil implements rebase, it will not forget old versions. What I'm interested in is the 'feature' of rebase where it can re-apply changes to a new a new head. The result may be in a new branch. - Altu -Original Message- From: Eric To: fossil-users@lists.fossil-scm.org Sent: Wed, Jun 23, 2010 12:27 pm Subject: Re: [fossil-users] fossil rebase > Hi,>> Is there a rebase feature in fossil that is similar to git rebase? If> not, is it planned?>> - AltuAnd what is different sincehttp://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg017 89.html?Eric___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
Re: [fossil-users] fossil rebase
> Hi, > > Is there a rebase feature in fossil that is similar to git rebase? If > not, is it planned? > > - Altu And what is different since http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01789.html ? Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
