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 > <alaric<ala...@snell-pym.org.uk> @snell- <ala...@snell-pym.org.uk>pym.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
