Re: [fossil-users] fine(r) commit granularity
On 8/6/2015 5:24 PM, Warren Young wrote: On Aug 5, 2015, at 9:45 AM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/4/2015 3:53 PM, Warren Young wrote: the chunks might have been modified before being checked in. Stash saves the contents of the new file, along with the baseline version. It does not save a list of diffs from the old to the new. Hmmm…that means if you modify a chunk before checking it in, the next --partial call will offer to *reverse* the changes you just made to that chunk. Kind of annoying. Guess that means the stash would also need to be updated to merge the extra changes back. This gets complicated to point that doing things by hand doesn't look so bad anymore. If someone can figure out a nice way to handle it, great. But I'm not really interested in doing that work myself since I have a process. The process is bothersome enough to discourage the underlying problem, that being making a lot of changes without being diligent about checking them in as logical units. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital 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] fine(r) commit granularity
On Aug 5, 2015, at 9:45 AM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/4/2015 3:53 PM, Warren Young wrote: the chunks might have been modified before being checked in. Stash saves the contents of the new file, along with the baseline version. It does not save a list of diffs from the old to the new. Hmmm…that means if you modify a chunk before checking it in, the next --partial call will offer to *reverse* the changes you just made to that chunk. Kind of annoying. ___ 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] fine(r) commit granularity
On 8/4/2015 3:53 PM, Warren Young wrote: It would be insufficient for apply --partial to just learn to recognize already-applied diff chunks as patch(1) does, because the chunks might have been modified before being checked in. Thus, a robust implementation of apply --partial would need to have a list of chunks you previously said “yes” to, so it can skip them the next time. Stash saves the contents of the new file, along with the baseline version. It does not save a list of diffs from the old to the new. If you manually apply a few of the diff chunks by hand (presumably after seeing them in stash show), stash pop or stash apply simply leverage the existing merge code to bring in the rest. $ f new x.fossil $ mkdir x $ cd x $ echo -e '1\n2\n3' file $ f add file $ f commit -m 1 $ echo -e '0\n1\n2\n3\n4' file $ f stash save -m s $ f stash show CHANGED file --- file +++ file @@ -1,3 +1,5 @@ +0 1 2 3 +4 $ echo -e '0\n1\n2\n3' file $ f stash pop MERGE file $ cat file 0 1 2 3 4 -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital 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] fine(r) commit granularity
On Aug 4, 2015, at 1:18 PM, Warren Young w...@etr-usa.com wrote: On Aug 4, 2015, at 8:51 AM, Ron W ronw.m...@gmail.com wrote: Also, if pop --partial were also implemented I think “pop --partial” only makes sense if it actually modifies the stash to contain only the un-popped partial changes, which seems a bit…excessive for v1 of this feature. I’ve rethought this. “fossil stash pop --partial” would be easier to implement than apply --partial. It would be insufficient for apply --partial to just learn to recognize already-applied diff chunks as patch(1) does, because the chunks might have been modified before being checked in. Thus, a robust implementation of apply --partial would need to have a list of chunks you previously said “yes” to, so it can skip them the next time. Because pop --partial could just rewrite the stash after each run, it wouldn’t need that secondary storage area, making it considerably easier to write. ___ 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] fine(r) commit granularity
On Aug 4, 2015, at 8:51 AM, Ron W ronw.m...@gmail.com wrote: An implicit pop would be contrary to the normal behavior of apply”. That’s fine. It’s very much a nonessential part of the design. Just trying to save someone a step there. Also, if pop --partial were also implemented, not popping would be contrary to its normal behavior, though would be a less shocking surprise. I think “pop --partial” only makes sense if it actually modifies the stash to contain only the un-popped partial changes, which seems a bit…excessive for v1 of this feature. ___ 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] fine(r) commit granularity
On 7/28/2015 9:18 PM, Warren Young wrote: On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? That said, it would be spiffy to have a “fossil ci --cherrypick” option that would ask me yes/no questions about each diff section, then commit all those I said “yes” to, leaving the “no” sections uncommitted. I've wanted this too, but I know it's a bad idea. The trouble is that each commit ought to first be tested (at least checked to be sure it compiles). Partial commits (even checking in only selected files) result in the committed version not matching the on-disk version therefore not being tested. When you realize you've made more than one check-in's worth of edits, run fossil stash save to save what you have and revert to your baseline. Do fossil stash show to review the not-yet-committed changes, and apply pieces by hand. Or do fossil stash apply to put all the remaining changes in place, then selectively back out changes. I do this in vim by opening a file, typing :new to vertically split with a new buffer, then typing :%!fossil cat FILENAME in that new buffer to load the committed version, then doing :diffthis in each buffer to get a side-by-side comparison. Many features are available, but usually I type do and dp to obtain and push changes between the current and other buffer. Another approach I've used when not using Fossil is to rename my changed files to have .new or such at the end of the name, revert to the last checked-in version, then pull changes from the .new one at a time, testing and committing after each. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital 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] fine(r) commit granularity
On Aug 3, 2015, at 1:08 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 7/28/2015 9:18 PM, Warren Young wrote: On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file it would be spiffy to have a “fossil ci —cherrypick” option ...it's a bad idea...each commit ought to first be tested...fossil stash save” Okay, how about this design, then: $ fossil stash save -m “several unrelated changes” $ fossil stash apply --partial ...fossil interactively asks whether to apply each diff chunk $ make test vi make test vi... $ fossil ci -m “one coherent change” $ fossil stash apply --partial ...another interrogation, skipping previously-applied chunks $ make test fossil ci -m “a second coherent change” ...GOTO 10 :) If you say “apply --partial” and Fossil sees that all stashed chunks are already applied, it could implicitly do “stash pop” instead, since there is no data loss. If you go through an “apply --partial” pass and accept none of the offered diff chunks, it could just ask if you meant to say “stash pop”, but not do it automatically. ___ 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] fine(r) commit granularity
On 3 August 2015 at 21:08, Andy Goth andrew.m.g...@gmail.com wrote: On 7/28/2015 9:18 PM, Warren Young wrote: On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? That said, it would be spiffy to have a “fossil ci --cherrypick” option that would ask me yes/no questions about each diff section, then commit all those I said “yes” to, leaving the “no” sections uncommitted. ... I do this in vim by opening a file, typing :new to vertically split with a new buffer, then typing :%!fossil cat FILENAME in that new buffer to load the committed version, then doing :diffthis in each buffer to get a side-by-side comparison. Many features are available, but usually I type do and dp to obtain and push changes between the current and other buffer. Thanks for reminding me - Vim's diff-functionality is indeed excellent for this, I use it often for side-by-side differ, not to get/put chunks of code - nice. Something similar in one line for Bash-users: vim -d myfile ( fossil cat myfile ) FWIW, I try to have small commits here; occasionally when unrelated changes have been made in a single file, I simply use the word 'and' in the commit-message, and that's about it. I agree that manually To make check-in of a selection of the changed files, some suggestions were made on this list other than doing 'fossil commit file1 file2 ...'; perhaps Fuel (https://fuel-scm.org/fossil/index) is interesting, but I haven't tried it myself. (But then again, I don't think this was the original Q.) Michai ___ 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] fine(r) commit granularity
grr... On 3 August 2015 at 21:50, Michai Ramakers m.ramak...@gmail.com wrote: FWIW, I try to have small commits here; occasionally when unrelated changes have been made in a single file, I simply use the word 'and' in the commit-message, and that's about it. I agree that manually ...selecting chunks of code to check in is not something I would do often, if ever. Michai ___ 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] fine(r) commit granularity
On Wed, Jul 29, 2015 at 6:34 AM, Steve Stefanovich s...@stef.rs wrote: From: Paolo Bolzoni Sent: Wednesday, 29 July 2015 08:38 fossil commit filename might help you in your problem? It gets messy when there is a number of files, on Windows at least where using pipes and xargs is limited compared to Unix. Sorry, I have no experience with Windows. ___ 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] fine(r) commit granularity
fossil commit filename might help you in your problem? On Tue, Jul 28, 2015 at 5:32 PM, Gour g...@atmarama.net wrote: Hello, recently I was submtting some package-build scripts to one Linux distro and had to use Git - from within Emacs along with Magit interface. Somehow, the nad had arisen to use Magit’t ability to split diff into smaller chunks and do commit with fine(r) granularity which reminded me of the feature which was available long ago in Darcs’ “record” command which has ’-i’ option to interactively record/commit changes. Now I wonder if there is some way to do the same with Fossil and/or what do you think about such feature, iow. split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. ___ 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] fine(r) commit granularity
On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? Whenever I need to do that, I say “fossil diff x.patch”, revert the local checkout, then manually divide up x.patch into the individual change sets. It’s a good painful lesson that reminds me to commit often. :) That said, it would be spiffy to have a “fossil ci --cherrypick” option that would ask me yes/no questions about each diff section, then commit all those I said “yes” to, leaving the “no” sections uncommitted. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fine(r) commit granularity
Hello, recently I was submtting some package-build scripts to one Linux distro and had to use Git - from within Emacs along with Magit interface. Somehow, the nad had arisen to use Magit’t ability to split diff into smaller chunks and do commit with fine(r) granularity which reminded me of the feature which was available long ago in Darcs’ “record” command which has ’-i’ option to interactively record/commit changes. Now I wonder if there is some way to do the same with Fossil and/or what do you think about such feature, iow. split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. ___ 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] fine(r) commit granularity
From: Paolo Bolzoni Sent: Wednesday, 29 July 2015 08:38 fossil commit filename might help you in your problem? It gets messy when there is a number of files, on Windows at least where using pipes and xargs is limited compared to Unix. On Tue, Jul 28, 2015 at 5:32 PM, Gour g...@atmarama.net wrote: what do you think about such feature, iow. split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? I think it would be useful, especially with complicated merges or when you have to revert bits out of the release. (I assume you propose something along the lines fossil commit --incremental where you would get prompted if you want to commit a particular file or not.) I use stash now to deal with this, but this would be easier. Cheers, Steve ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
