Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDluxYACgkQRgz/WHNxCGp4HQCghgq9q1JuvzndW3tlkj0zXNS1 2XsAn0GS6hdXXtvj0C7aXBWvoDYDidjL =S55G -END 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] Fossil vs. Git/Mercurial/etc.?
On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDluxYACgkQRgz/WHNxCGp4HQCghgq9q1JuvzndW3tlkj0zXNS1 2XsAn0GS6hdXXtvj0C7aXBWvoDYDidjL =S55G -END PGP SIGNATURE- ___ 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 vs. Git/Mercurial/etc.?
Hello, In my opinion, the private branch concept only works well for people working in just one computer. In the every day more common case of people developing in several computers (desktop, laptop, tablet, etc), private branches do not adapt well to the situation. Probably the solution could be the combination of two concepts that have already been discussed in the past: 1- Selective sync of some branches depending on the remote repository 2- Mark some commits as hidden and do not show them in a normal timeline RR 2013/1/3 Richard Hipp d...@sqlite.org: If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change ___ 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 vs. Git/Mercurial/etc.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 3 Jan 2013 12:12:53 -0500 Richard Hipp drh-czdrofg0bjidnm+yrof...@public.gmane.org wrote: If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. That's fine, Richard, but we need ability to select single private branches while pushing as well as getting rid of them. Sincerely, Gour - -- For him who has conquered the mind, the mind is the best of friends; but for one who has failed to do so, his mind will remain the greatest enemy. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQ5eM2AAoJELhxXPVStcgQ4QoQAJO8eMu4x+O0Ay0tALlFIDnJ 3ruiL8W5qjuN4ZpaTdTjFJ7Hb0aoupXT0w6UwDtdFl7ui0ELQnz1+yZd6RnKXBLH wHhaxAbS5oJVz6lD8sJgATEYFAP/F9ojUA2Wb/Jf0CVTSIWkLee754kxROpBOFJB YnLhqIYDVG8LSSR6hIp31LYUdFok1Y+Rk5waGzHCx2zcwPx3ynLRc+0lRNxTHGYS wt3hO9zKAeuzrB+JeCYPrGMgYeuUGrYPqCIoPCcVZs0JaX4xjxlhLluS2x/RGyHC r/5zW3pHkw0nJUOjZ0kfu+p8iRCbtY8pWpkZjVeNma2hdnAVyWNBCcfuRq3gLCVU N7PjBtUP4+pGQHbUw5ivLBfnEsfLQ9feU1zTCzRI411FcjWCE+pMwTVF8WilMDhC 7PnlUffqQGGZArRwyUZYkN8I5tz05KXFrLxn0PxerNMoVrZUOoxrOHx8aIK7LKPA pxndVDMMLrJ0F0ifFhCLF7olLlCuY6dt/Ru4PaSgI25bCRfWT2Sqjw1Sfya00k6H j623e64GBPxuQi9BLRI2mqtyiTJThq8moQKzHa47SbOFq0p+Av2gO6X5t9DaWbcy r7sJbaAobJ5PmgI4EtEOOnww8BDB2YgHwKqVdcSDd34zqFMtk0KT779M089WEOER khtixD03/dFquCZGBAkH =x9B8 -END 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] Fossil vs. Git/Mercurial/etc.?
On Jan 3, 2013 12:13 PM, Richard Hipp drh d...@sqlite.org@d...@sqlite.org sqlite.org d...@sqlite.org wrote: On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym alaricala...@snell-pym.org.uk @snell- ala...@snell-pym.org.ukpym.org.uk ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. The changes might need to be logically broken up into several commits. So rather than squash everything into one commit the recipe might need to be more involved. For example, in developing the commits on that branch for some feature i might also have fixed bugs that need to be fixed separately upstream so that they can get cherry-picked onto branches for older release maintenance. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
