Re: [fossil-users] "losing" history in private branch merge?
On Fri, 25 May 2012 15:28:02 -0400 Richard Hipp wrote: > So perhaps we should go back to the original design? As far as private branches are concerned, I'd like to be able to selectively rm single private branch when using 'scrub'. Otoh, Mercurial has nice concept of Phases (http://mercurial.selenic.com/wiki/Phases) controlling how changesets are exchanged, Moreover, 2.3 is preparing another interesting concept: http://hg-lab.logilab.org/doc/mutable-history/html/obs-concept.html Sincerely, Gour -- A person is considered still further advanced when he regards honest well-wishers, affectionate benefactors, the neutral, mediators, the envious, friends and enemies, the pious and the sinners all with an equal mind. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ 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] "losing" history in private branch merge?
On 5/25/2012 12:28 PM, Richard Hipp wrote: So, clearly, I just need to revisit the whole "private branch" concept As originally implemented, private branches were just a marking in the database. But then somebody (aku?) While I don't remember that, it would certainly be in my line of thinking on seeing such a design. > pointed out that if you export and reimport the database, the private markings are lost, since database entries are not preserved on import/export. So then I started adding the "private" tag to private branches. So now I find that these tags are hard to get rid of. So perhaps we should go back to the original design? -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato http://www.eurotcl.tcl3d.org/ - EuroTcl 2012, July 7-8 , Munich, Germany. http://www.tcl.tk/community/tcl2012/ - Tcl'2012, Nov 12-16, Chicago, IL, USA. ___ 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] "losing" history in private branch merge?
So, clearly, I just need to revisit the whole "private branch" concept As originally implemented, private branches were just a marking in the database. But then somebody (aku?) pointed out that if you export and reimport the database, the private markings are lost, since database entries are not preserved on import/export. So then I started adding the "private" tag to private branches. So now I find that these tags are hard to get rid of. So perhaps we should go back to the original design? -- 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] "losing" history in private branch merge?
On Fri, 25 May 2012 17:41:44 + wrote: > On Fri, 25 May 2012 13:34:54 -0400 > Richard Hipp wrote: > > > I don't think so, not other than checking each one out and > > recommitting them one by one. To do otherwise would be changing the > > history of the project, which Fossil does not allow (by design). > > That's fine. > > Which commands should I use to do the above? I want to avoid screwing > things up even further, so I'd like to be sure... Expecting disaster, I made a copy of the database. I shunned the merge commit from the web interface. Then, for each commit in the private branch, I attempted to merge the private commit with the current trunk (which had not changed since the start of the private branch). Within two commits, I somehow had merge conflicts (how is that even possible?) and files from a commit that I'd not yet merged. Assuming I'd done something wrong, I went back to the original copy of the database and tried again. Same result. I give up. ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 12:26 PM, Nolan Darilek wrote: > Shame, I actually kind of liked that individual commits were preserved. > Squashing and such was part of why I left Git. History should be preserved, > whether you are working alone in private or in the open. History is preserved in your private branch for your private perusal, isn't it? To borrow some C++ lingo, it sounds like what you're looking for might be better called a 'protected' branch. Or if necessary disable auto-sync and publicly branch until you're done with it, optionally on another clone of the repository. Or probably other things I can't think of at the moment. The desired functionality is there, just not the way you were expecting it, probably. Note: I don't mean for the above to come off terse or rude or condescendingly. Just observing some other possible solutions that haven't been mentioned yet that will publicly preserve history in a way that works with the existing system. SDR ___ 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] "losing" history in private branch merge?
On 05/25/2012 11:10 AM, org.fossil-scm.fossil-us...@io7m.com wrote: That's one interpretation of private, yes. I took it to mean that the branch wouldn't be synced, or visible, on any remotes. I don't think that necessarily implies coalescing commits like that... If it's not possible, I can live with it, I'll just switch to only using public branches. This was my interpretation of how the feature worked as well, having never used it before. Shame, I actually kind of liked that individual commits were preserved. Squashing and such was part of why I left Git. History should be preserved, whether you are working alone in private or in the open. ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 01:53:23PM -0400, Richard Hipp wrote: > On Fri, May 25, 2012 at 1:51 PM, Lluís Batlle i Rossell > wrote: > > Ah, I thought that branches could be made back public easily. I never used > > privated branches still, so I have zero practise with them. > > > > As for the tag, Why it does not work as in an inherited tag? > > > > The "private" tag is hard-coded onto every check-in of a private branch. > You can override the tag later. But there is still a new instance of the > tag on every check-in and each new instance has to be cancelled separately. Sorry for the misunderstanding; for 'why', I meant if it can be changed to use an inherited tag, instead of hardcoding it at every checkin. What do you think of supporting some way of making a private branch public? Thank you, Lluís. ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 1:51 PM, Lluís Batlle i Rossell wrote: > On Fri, May 25, 2012 at 01:49:06PM -0400, Richard Hipp wrote: > > On Fri, May 25, 2012 at 1:42 PM, Lluís Batlle i Rossell < > vi...@viric.name>wrote: > > > > > > > > > > I don't think so, not other than checking each one out and > recommitting > > > > them one by one. To do otherwise would be changing the history of > the > > > > project, which Fossil does not allow (by design). > > > > > > Couldn't the branch be made public just before merging? > > > > > > > > > There is no easy way to make a branch public. It *might* work to go > > through an cancel the "private" tag on each check-in of the branch, then > > run "rebuild". Emphasis is on the word "might" because I have never > > actually tried to do that. And, there is no way that I know of to cancel > > the tag on all checkins of a branch all at once - you'd have to do them > one > > by one. > > Ah, I thought that branches could be made back public easily. I never used > privated branches still, so I have zero practise with them. > > As for the tag, Why it does not work as in an inherited tag? > The "private" tag is hard-coded onto every check-in of a private branch. You can override the tag later. But there is still a new instance of the tag on every check-in and each new instance has to be cancelled separately. > > Thank you, > Lluís. > ___ > 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 01:49:06PM -0400, Richard Hipp wrote: > On Fri, May 25, 2012 at 1:42 PM, Lluís Batlle i Rossell > wrote: > > > > > > > I don't think so, not other than checking each one out and recommitting > > > them one by one. To do otherwise would be changing the history of the > > > project, which Fossil does not allow (by design). > > > > Couldn't the branch be made public just before merging? > > > > > There is no easy way to make a branch public. It *might* work to go > through an cancel the "private" tag on each check-in of the branch, then > run "rebuild". Emphasis is on the word "might" because I have never > actually tried to do that. And, there is no way that I know of to cancel > the tag on all checkins of a branch all at once - you'd have to do them one > by one. Ah, I thought that branches could be made back public easily. I never used privated branches still, so I have zero practise with them. As for the tag, Why it does not work as in an inherited tag? Thank you, Lluís. ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 1:42 PM, Lluís Batlle i Rossell wrote: > > > > I don't think so, not other than checking each one out and recommitting > > them one by one. To do otherwise would be changing the history of the > > project, which Fossil does not allow (by design). > > Couldn't the branch be made public just before merging? > There is no easy way to make a branch public. It *might* work to go through an cancel the "private" tag on each check-in of the branch, then run "rebuild". Emphasis is on the word "might" because I have never actually tried to do that. And, there is no way that I know of to cancel the tag on all checkins of a branch all at once - you'd have to do them one by one. > ___ > 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 01:34:54PM -0400, Richard Hipp wrote: > On Fri, May 25, 2012 at 1:09 PM, wrote: > > > On Fri, 25 May 2012 16:10:44 + > > wrote: > > > > > On Fri, 25 May 2012 11:53:35 -0400 > > > Richard Hipp wrote: > > > > > > > On Fri, May 25, 2012 at 11:42 AM, > > > > wrote: > > > > > Is it possible to avoid squashing all private commits into one? > > > > > > > > > > > > > The branch is private. If all the individual commits where pushed > > > > out to the world, it wouldn't be private any more and the whole > > > > purpose of having a private branch would be defeated, no? > > > > > > > > > > That's one interpretation of private, yes. I took it to mean that the > > > branch wouldn't be synced, or visible, on any remotes. I don't think > > > that necessarily implies coalescing commits like that... > > > > > > If it's not possible, I can live with it, I'll just switch to only > > > using public branches. > > > > Is it possible to get those commits into trunk in any way? Losing the > > details isn't acceptable (due to my misunderstanding of exactly what > > a private branch entailed). > > > > I don't think so, not other than checking each one out and recommitting > them one by one. To do otherwise would be changing the history of the > project, which Fossil does not allow (by design). Couldn't the branch be made public just before merging? ___ 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] "losing" history in private branch merge?
On Fri, 25 May 2012 13:34:54 -0400 Richard Hipp wrote: > I don't think so, not other than checking each one out and > recommitting them one by one. To do otherwise would be changing the > history of the project, which Fossil does not allow (by design). That's fine. Which commands should I use to do the above? I want to avoid screwing things up even further, so I'd like to be sure... ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 1:09 PM, wrote: > On Fri, 25 May 2012 16:10:44 + > wrote: > > > On Fri, 25 May 2012 11:53:35 -0400 > > Richard Hipp wrote: > > > > > On Fri, May 25, 2012 at 11:42 AM, > > > wrote: > > > > Is it possible to avoid squashing all private commits into one? > > > > > > > > > > The branch is private. If all the individual commits where pushed > > > out to the world, it wouldn't be private any more and the whole > > > purpose of having a private branch would be defeated, no? > > > > > > > That's one interpretation of private, yes. I took it to mean that the > > branch wouldn't be synced, or visible, on any remotes. I don't think > > that necessarily implies coalescing commits like that... > > > > If it's not possible, I can live with it, I'll just switch to only > > using public branches. > > Is it possible to get those commits into trunk in any way? Losing the > details isn't acceptable (due to my misunderstanding of exactly what > a private branch entailed). > I don't think so, not other than checking each one out and recommitting them one by one. To do otherwise would be changing the history of the project, which Fossil does not allow (by design). > > ___ > 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] "losing" history in private branch merge?
On Fri, 25 May 2012 10:18:34 -0700 Matt Welland wrote: > On Fri, May 25, 2012 at 9:10 AM, > wrote: > > > On Fri, 25 May 2012 11:53:35 -0400 > > Richard Hipp wrote: > > > > > On Fri, May 25, 2012 at 11:42 AM, > > > wrote: > > > > Is it possible to avoid squashing all private commits into one? > > > > > > > > > > The branch is private. If all the individual commits where pushed > > > out to the world, it wouldn't be private any more and the whole > > > purpose of having a private branch would be defeated, no? > > > > > > > That's one interpretation of private, yes. I took it to mean that > > the branch wouldn't be synced, or visible, on any remotes. I don't > > think that necessarily implies coalescing commits like that... > > > > If it's not possible, I can live with it, I'll just switch to only > > using public branches. > > > It sounds like the request would be able to switch a branch from > private to public. That seems like it would be a very powerful > feature (assuming it is not already possible?). Yeah, I think the direct approach would be (if the feature existed): 1. Undo the "merge" commit (perhaps by shunning). 2. Mark the private branch as public. 3. Merge again. ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 9:10 AM, wrote: > On Fri, 25 May 2012 11:53:35 -0400 > Richard Hipp wrote: > > > On Fri, May 25, 2012 at 11:42 AM, > > wrote: > > > Is it possible to avoid squashing all private commits into one? > > > > > > > The branch is private. If all the individual commits where pushed > > out to the world, it wouldn't be private any more and the whole > > purpose of having a private branch would be defeated, no? > > > > That's one interpretation of private, yes. I took it to mean that the > branch wouldn't be synced, or visible, on any remotes. I don't think > that necessarily implies coalescing commits like that... > > If it's not possible, I can live with it, I'll just switch to only using > public branches. It sounds like the request would be able to switch a branch from private to public. That seems like it would be a very powerful feature (assuming it is not already possible?). > > ___ > 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] "losing" history in private branch merge?
On Fri, 25 May 2012 16:10:44 + wrote: > On Fri, 25 May 2012 11:53:35 -0400 > Richard Hipp wrote: > > > On Fri, May 25, 2012 at 11:42 AM, > > wrote: > > > Is it possible to avoid squashing all private commits into one? > > > > > > > The branch is private. If all the individual commits where pushed > > out to the world, it wouldn't be private any more and the whole > > purpose of having a private branch would be defeated, no? > > > > That's one interpretation of private, yes. I took it to mean that the > branch wouldn't be synced, or visible, on any remotes. I don't think > that necessarily implies coalescing commits like that... > > If it's not possible, I can live with it, I'll just switch to only > using public branches. Is it possible to get those commits into trunk in any way? Losing the details isn't acceptable (due to my misunderstanding of exactly what a private branch entailed). ___ 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] "losing" history in private branch merge?
On Fri, 25 May 2012 11:53:35 -0400 Richard Hipp wrote: > On Fri, May 25, 2012 at 11:42 AM, > wrote: > > Is it possible to avoid squashing all private commits into one? > > > > The branch is private. If all the individual commits where pushed > out to the world, it wouldn't be private any more and the whole > purpose of having a private branch would be defeated, no? > That's one interpretation of private, yes. I took it to mean that the branch wouldn't be synced, or visible, on any remotes. I don't think that necessarily implies coalescing commits like that... If it's not possible, I can live with it, I'll just switch to only using public branches. ___ 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] "losing" history in private branch merge?
On Fri, May 25, 2012 at 11:42 AM, wrote: > Hello. > > 1) I created a private branch, made several commits, and then merged the > private branch with the current trunk. Rather than seeing the commits > I made on the private branch in the timeline for the trunk, I only see > the one large commit resulting from accumulating all the smaller commits > into one when merging. > > Is it possible to avoid squashing all private commits into one? > The branch is private. If all the individual commits where pushed out to the world, it wouldn't be private any more and the whole purpose of having a private branch would be defeated, no? > > 2) Additionally, as auto-sync was enabled, the large commit was pushed > to a remote. I realize it's not possible to rewrite history (nor would I > want to), but is there some way to push any changes I make whilst trying > to sort out item 1 above (so that the private commits are visible)? > ___ > 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
[fossil-users] "losing" history in private branch merge?
Hello. 1) I created a private branch, made several commits, and then merged the private branch with the current trunk. Rather than seeing the commits I made on the private branch in the timeline for the trunk, I only see the one large commit resulting from accumulating all the smaller commits into one when merging. Is it possible to avoid squashing all private commits into one? 2) Additionally, as auto-sync was enabled, the large commit was pushed to a remote. I realize it's not possible to rewrite history (nor would I want to), but is there some way to push any changes I make whilst trying to sort out item 1 above (so that the private commits are visible)? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
