Re: [fossil-users] Select specific changes within files
On Fri, Mar 20, 2015 at 7:26 PM, Andy Bradford wrote: > > Or the opposite. Stash and partial pop, which apparently Fossil can > already handle simply by using the ``right'' diff tool. For example, I > configured Fossil to use idiff as my gdiff command > > $ fossil set gdiff-command idiff > > Now I can run fossil stash gdiff and interactive diff will allow me to > selectively apply the diff > Excellent! I'm a fan of 'git add -i' and if this gets me that equivalent functionality in fossil, I'll learn to use it. Thanks! -- Rich ___ 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] Select specific changes within files
Thus said Ron W on Fri, 20 Mar 2015 15:56:51 -0400: > I've never seen a non-gui, interactive merge, so I don't know how > feasible to create such a tool Here's a non-gui, interactive merge (I didn't show it, but there is also an edit command which invokes $EDITOR on just the chunk in question to allow you to correct for overlaps such as the one for ``line 3'': $ fossil settings gdiff-command idiff $ fossil stash gdif CHANGED file 3c3,4 < line 3 --- > Line 3 > Line 4 ? < 7c8 < Lin3 8 --- > Line 8 ? > idiff output in file idiff.out $ cp idiff.out file $ fossil diff Index: file == --- file +++ file @@ -2,8 +2,8 @@ Line 2 line 3 Line 5 Line 6 Line 7 -Lin3 8 +Line 8 Line 9 Line 10 $ fossil ci -m done New_Version: 4939f3582aa15aa4739b713b232c8feeb34cbc8b Andy -- TAI64 timestamp: 4000550cc043 ___ 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] Select specific changes within files
Thus said Marcel Graf on Fri, 20 Mar 2015 18:30:11 +0100: > Imho, the "missing piece" would be "stash" having means to do partial > stashing (finer than on file-by-file base). This the would allow to do > these "splittings of a mixed up check-outs" a bit easier (including > testing "before" committing, no need for "partial commit" then), > wouldn't it? Or the opposite. Stash and partial pop, which apparently Fossil can already handle simply by using the ``right'' diff tool. For example, I configured Fossil to use idiff as my gdiff command $ fossil set gdiff-command idiff Now I can run fossil stash gdiff and interactive diff will allow me to selectively apply the diff There may be better tools than idiff, but honestly, given that there are already tools out there that do this, and Fossil allows one to choose a gdiff-command, must Fossil also have this same code? Just my $0.02. Andy -- TAI64 timestamp: 4000550cbabc ___ 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] Select specific changes within files
Thus said Abilio Marques on Fri, 20 Mar 2015 13:58:33 -0430: > Then I start to work in a new feature, and I add 10 functions (I will > only show one here). Now that you know about it, can the start of a new feature also involve another fossil open of the repository for said feature? Thanks, Andy -- TAI64 timestamp: 4000550cb414 ___ 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] Select specific changes within files
++1 From: Scott Robison Sent: Friday, March 20, 2015 11:08 PM On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich wrote: If we are discussing "partial", I'm more interested in partial checkouts than partial commits, i.e. having the ability to checkout a specific directory only. Now that would be useful for us with big source trees where there are third party components included. +1 -- Scott Robison ___ 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] Select specific changes within files
Thus said Ron W on Fri, 20 Mar 2015 13:19:58 -0400: > Never too late to stash. If I decide I need to split out changes > already made, I stash the files, then do "fossil stash gdiff" to > selectively (re) apply the stashed changes, then build/test/commit. gdiff allows you to selectively apply part of the stash? If so, it seems like Fossil already has partial commit support. :-) /me needs to look at gdiff... Andy -- TAI64 timestamp: 4000550cb28f ___ 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] Select specific changes within files
Thus said Richard Hipp on Fri, 20 Mar 2015 13:04:44 -0400: > (1) Make logically separate changes in separate check-outs so that > they are easy to test and commit separately. I think this ability to have multiple checkouts of the same repository is a much more elegant solution, but it does require one to impose some modicum of discipline in one's workflow. As you say, it is possible to accidentally make changes where one did not want them, and yes, this may require some clean up, but is partial commit support optimizing for an edge case? Fossil has stash. It supports multiple opens of the same repository on different branches. It is already relatively (I mean relative to git) easier to clean up mistakes; I've never felt like ``I'm a bad person and must rewrite history[1]'' because Fossil make recovering from these things much easier. In my time using git I have never actually once used partial commits. How often do git users on this list use partial commits? [1] http://sethrobertson.github.io/GitFixUm/fixup.html#pushed_old Thanks, Andy -- TAI64 timestamp: 4000550cb1ae ___ 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] Select specific changes within files
Thus said Stephan Beal on Fri, 20 Mar 2015 13:45:14 +0100: > IMO it's inherently evil because it promotes checking in untested > subsets. Automated tests require a full, valid tree. Checking in a > part of a change may well lead to code which runs on your machine but > doesn't run on remotes (continuous integration systems or other > users). The biggest difference being that with git, your commit is not automatically pushed. So it's alright to commit partial changes because they won't go anywhere and remain local until you actually pull and then push (or make a pull request). With Fossil, on the other hand, the default sync mode is autosync which means that committing a partial commit could be much more dangerous than in git. Andy -- TAI64 timestamp: 4000550cab48 ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 4:55 PM, Steve Stefanovich wrote: > > If we are discussing "partial", I'm more interested in partial checkouts > than partial commits, i.e. having the ability to checkout a specific > directory only. Now that would be useful for us with big source trees where > there are third party components included. > ++ ___ 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] Select specific changes within files
On 20 March 2015 at 13:55, Steve Stefanovich wrote: > If we are discussing "partial", I'm more interested in partial checkouts than > partial commits, i.e. having the ability to checkout a specific directory > only. Now that would be useful for us with big source trees where there are > third party components included. +1 Another interesting idea for Fossil: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19270.html -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich wrote: > If we are discussing "partial", I'm more interested in partial checkouts > than partial commits, i.e. having the ability to checkout a specific > directory only. Now that would be useful for us with big source trees where > there are third party components included. > +1 -- Scott Robison ___ 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] Select specific changes within files
I feel exactly like below little excerpt from recent drh's email on the subject. There other bits of Fossil that are more important - to me, at least - to spend time on, like polishing search, improving wiki and ticketing default setup, etc. If we are discussing "partial", I'm more interested in partial checkouts than partial commits, i.e. having the ability to checkout a specific directory only. Now that would be useful for us with big source trees where there are third party components included. Original Message From: Richard Hipp Sent: Saturday, 21 March 2015 04:05 Subject: Re: [fossil-users] Select specific changes within files ...We shouldn't waste too much time implementing that capability when there are other more useful features that could be added instead... ___ 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] Select specific changes within files
On 2015-03-20 15:56:51, Ron W wrote: > I've never seen a non-gui, interactive merge, so I don't know how feasible > to create such a tool Have a look at sdiff from e.g. GNU diffutils, invoked with the -o option. Regards, -Martin ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 3:32 PM, Marcel Graf wrote: > > I was more thinking about a command line only version of stash/snapshot > --interactive asking for each file if i want it entirely or split and in > case of the latter, letting me select each chunk without the use of an > external gui (I vaguely remember mercurial's record extension doing > something like this). But might not be worth it and/or induce to many > options to stash ... > To interactively select file-by-file which files to stash should be not hard. Selecting chunks of code with in a file is a lot more work, but still possible. Basically a variation on a non-gui, interactive merge. The input pair would be the edited file and its baseline. Then where a difference is detected, the tool shows the 2 versions of the differing block of lines, along with context, and prompts the user to choose which of the 2, then outputs the chosen variant to the output file. Then the content output file would be put in the stash. I've never seen a non-gui, interactive merge, so I don't know how feasible to create such a tool But, generically speaking, a selective stash operation would provide the edited file and its baseline to a configurable tool that would produce a third file that Fossil would then put the content thereof in the stash for the edited file. ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 7:14 PM, Ron W wrote: > On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf > wrote: > >> On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp wrote: >> >>> On 3/20/15, Martin S. Weber wrote: >>> ... >> >> > in itself). So you end up with intermingled changes which one would >>> > like to split cleanly. >>> > >>> The way I deal with this in SQLite is: >>> ... >> >> (2) On the occasions when I mess up and accidentally put unrelated >>> changes into the same check-out, I have been known to stash the whole >>> thing, then reapply one set of changes, test, commit, then reapply the >>> other set of changes, test, and commit again. >> >> >> This (2) might be easier with something like a >> "partial/selective/interactive stash" as mentioned by the OP in the bottom >> part of his email. >> So (2a) would look like: selectively stash the "second" set of changes, >> test (thus including the "first" set of changes), commit, stash pop/apply >> "second", test, commit >> > > I suppose this would make sense if there are fewer changes to "undo" in > the edited code than to "re do" in the reverted code. > > > You can achieve the same result with "fossil snapshot" (which skips the > automatic revert), then "fossil gdiff" to selectively "undo" changes. Then > edit/build/test/commit what remains. After that, "fossil stash gdiff" to > selectively re-apply more changes. Repeat as needed > I assume you mean fossil stash snapshot. This will still "take" the whole thing (or a selection of entire files) and whatever diff-merge-gui I use for fossil gdiff will hopefully allow me to efficiently "undo" the changes of the "second" modification. Yes, that will do! And as you said, doing it "forward" or "backward" depends on the number of changes in the "first" vs the "second" modification. Or even split is up in one "stash save" for all files with only "second" modifications, one "stash snapshot" for the "mixed" ones and "undo" the parts from the "second". Test/commit, "stash apply 2" and "stash apply 1", test/commit. I was more thinking about a command line only version of stash/snapshot --interactive asking for each file if i want it entirely or split and in case of the latter, letting me select each chunk without the use of an external gui (I vaguely remember mercurial's record extension doing something like this). But might not be worth it and/or induce to many options to stash ... ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 2:28 PM, Abilio Marques wrote: > > So including that patch right now seems really important. But I have a mix > between the patch and the unfinished (and also untested). > > Until yesterday, what did I do? > > fossil stash snapshot > go to the editor, find the lines that I want to remove (all the ones from > the new feature), remove them. > test > commit > fossil stash pop > Since your patch is a smaller amount of code, what I might do is: fossil stash save # files will be automatically reverted fossil stash gdiff fileWithPatch.c # find line(s) with patch and apply to working copy build # test fossil ci -m 'Fix memory leak' Same end result with less work. ___ 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] Select specific changes within files
Ok, in an attempt to provide a short example:
The code is working, I have tests, yet I don't test for memory leaks.
That's my current scenario. A code snippet follows:
void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}
void functionB() {
functionA();
}
Then I start to work in a new feature, and I add 10 functions (I will only
show one here).
void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}
void functionB() {
functionA();
}
void functionC() {
for (i = 0; i < 12000; i++) {
functionA();
}
}
When I run the code it crashes (as it's running on a device with 8Mb of
RAM). I check the why... and I discover that thisWillLeak was never freed.
I'm busy working, so I accidentally add the free in the middle of my work
day, and continue to work on my new feature.
Today is a code freeze, and even when my new feature is not going to be
included, as is not complete, 4 hours later I think "hum, that memory leak
made my software crash because it tried to make 12000 allocations... but in
real life, if functionB, which runs every 5 minutes, gets called around
8192 times, it will surely make the system crash too, so that bug would be
a nasty one given less than a month"
So including that patch right now seems really important. But I have a mix
between the patch and the unfinished (and also untested).
Until yesterday, what did I do?
fossil stash snapshot
go to the editor, find the lines that I want to remove (all the ones from
the new feature), remove them.
test
commit
fossil stash pop
continue working as usual.
But there has also been times where I was working in some document (I use
LaTeX from time to time).
So I have a partial document on the repo. I continue committing every time
I add a new section. I'm in the middle of a section, and some friend kindly
pass by my computer and reads the document directly from the screen. Finds
a typo... I edit it right there (I'm not going to tell him... wait while I
go to the terminal and stash my current work so we can fix the typo,
normally I even forget I can do it while I'm doing the work all by
myself)... then after I finish the section, I do:
fossil diff
just to discover... ouch, I have this uncommitted typo fix too... I don't
want to commit both changes at once... so I need to go and repeat something
close to the previously described workflow.
The change in the first example (only adding a line with a free) seems
trivial, but sometimes there is more than 1 line involved and they are not
all together. Sometimes both the fix and the new feature are completely
independent, ie: instead of a leak, I find a way to rewrite 20 lines of
code, all scattered around, that make functionA a lot more efficient in
execution time than the actual code.
As functionC calls it 12000 times... improving speed execution of functionA
will reduce the time I must spend waiting for the test of functionC ends
(which I run several times as the new feature gets completed). So I
replaced it in the heat of the moment,without stashing... first commented
the line that uses functionC ran the program, worked faster... got happy,
I'll go to bed earlier, uncommented the call functionC and continue to
work...
At the end, I do a fossil diff... and I get the picture... both the speed
improvement idea and the new feature are mixed together...
I can proceed to stash either the speed improvement code or the new
feature, test the one that is not stashed, commit it after I'm happy, pop
the remaining code, and keep going.
Please forgive me if these examples seem trivial or too specific. I tried
to put 3 ones that come to my mind right now.
To finish the idea, I will use another example (this time generic).
touch a.txt
fossil ci -m "a is empty"
fossil add a.txt
echo "dog" >> a.txt
echo "cat" >> a.txt
echo "parrot" >> a.txt
echo "house" >> a.txt
echo "car" >> a.txt
fossil diff
I get
Index: a.txt
==
--- a.txt
+++ a.txt
@@ -0,0 +1,4 @@
+dog
+cat
+parrot
+house
+car
I discover that the animals, even when it should go into that file,
shouldn't go in the first commit). So I do:
fossil stash save --selectively -m "This stash removes the animals"
Somehow this (perhaps on the same way git does the add --edit, by opening a
text editor with the diff) let me deselect the lines that say "house" and
"car"... and bang. The commit can proceed only with house and car... then I
do fossil pop... that inlcudes the animals... and I can commit again, the
final version of the file.
The main question remains... is there a way to do that "selectively" thing.
Would stash the best place to add it. Is is possible to do so? And the most
important one... does it seem useful for a lot of people?
On Fri, Mar 20, 2015 at 1:05 PM, Martin S. Weber wrote:
> On 2015-03-20 13:04:44, Richard Hipp w
Re: [fossil-users] Select specific changes within files
Stephan Beal wrote: On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques mailto:abili...@gmail.com>> wrote: I personally would like a selective stash. Perhaps one where you can selectively push some changes (then fossil could proceed to remove them from the actual files), or selectively pop/apply some changes (but I imagine this one could get things confusing, specially if used with apply). ... What are your opinions? Is this useful? Is this powerful? What would your approaches be? IMO it's inherently evil because it promotes checking in untested subsets. Automated tests require a full, valid tree. Checking in a part of a change may well lead to code which runs on your machine but doesn't run on remotes (continuous integration systems or other users). A selective stash does not have these problems, since you're only removing files from the working tree; it does not change the repository, until you actually perform a (non-selective) commit. Second, there are ways to do selective commits without the above problems (assuming you find the feature desirable and worth the effort of implementing it). Give the commit command three subcommands: fossil commit --tentative fossil commit --amend fossil commit --finalize Here, `fossil commit --tentative` will begin a tentative commit. Such a commit cannot be exported from the repository (via push, bundle, etc.), but can be diffed against, viewed, etc. Then, `fossil commit --amend` can change the commit by adding files or individual hunks to it or removing them. Finally, once you're satisfied, you can use `fossil commit --finalize` to turn the tentative commit into a regular one (presumably after stashing all remaining changes and testing the commit). You can even be strict and require that the tree be clean for `fossil commit --finalize` to be permitted. (Note: This is essentially a greatly simplified version of how Mercurial Queues work.) Such an approach should fix most of the issues with the Git staging area, while retaining all its power; the main downside is that it adds a lot of potential complexity to `commit`, while a selective stash (and selective `stash apply`) would be equally powerful and much simpler to implement, understand, and teach. (Note: Bzr uses selective stash -- called shelve -- and full commits by default, and to good effect.) Reimer Behrends ___ 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] Select specific changes within files
On 2015-03-20T07:26:53 -0430 Abilio Marques wrote: > I personally would like a selective stash. This seems like the best of all worlds: You get the clean separate commits typical of git, but with each of those commits actually compiled and tested. I tried to put this together ages ago by producing a single diff from the stash and then interactively patching using some 3rd-party GUI patch tools, but it never really worked out (due to the 3rd-party tools not really doing it very well). It's basically the logic from git add --patch but working in reverse: Take a large diff, interactively split it into chunks and optionally apply some of the chunks. Compile. Test. Commit. Repeat until there are no chunks left. M ___ 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] Select specific changes within files
On 3/20/15, Richard Hipp wrote: > On 3/20/15, Martin S. Weber wrote: >> On 2015-03-20 09:02:32, Richard Hipp wrote: >>> (...) >>> I'm still having trouble understanding how the partial commit would be >>> *useful*, though. >> >> >> Also, ideally you're working in a flow anyways (the deep meditative >> state where stuff gets done (tm)); doing housekeeping (stashing here >> and there; grouping related changes to single commits so that you can >> cleanly test them / undo them as a human without the need for tools such >> as unit-testing combined with fossil bisect) is a safe way to kill any >> meditative effort (except for real housekeeping, obviously meditative >> in itself). So you end up with intermingled changes which one would >> like to split cleanly. >> > > The way I deal with this in SQLite is: > > (1) Make logically separate changes in separate check-outs so that > they are easy to test and commit separately. A real-life example of > this can be seen at https://www.sqlite.org/src/timeline?c=08958f57 - I > was working on the stat4-function branch when I noticed that an > unrelated comment needed to be cleaned up, so I checked in the comment > fix separately, then continued merrily working away on stat4-function. > > (2) On the occasions when I mess up and accidentally put unrelated > changes into the same check-out, I have been known to stash the whole > thing, then reapply one set of changes, test, commit, then reapply the > other set of changes, test, and commit again. > > (3) You might also check-in the whole thing into a side branch, then > do multiple partial merges back into the branch you were working on, > with appropriate comments on each merge. (To do the partial merge, > you merge the whole change, then back out the parts that you don't > want for the current partial merge, test and commit, then repeat. > Copy/Paste from "fossil diff --tk" gets this done rather efficiently, > in my experience.) > > You can argument that (2) might have been easier with a partial > commit. Maybe so; maybe a little easier, but not a huge amount > easier. And I would have had to skip the testing step, which might > have caused problems in the future such that the total effort (effort > to commit plus effort to fix problems caused by the untested commit) > is greater than the effort of applying procedure (2) as written. > > So one can argue that partial commit might save you (a little) effort > today, but will end up requiring more work in the long-term. > > Still, there will always be people who are convinced that there is > nothing that can go wrong and what to do a partial commit against > expert advise. I'm interested in exploring the idea of supporting some way to do "split commits", where two logical ideas end up in the same file in the same checkout, but to characterize that as "convinced that there is nothing that can go wrong" is disengenuous. What I've done so far is use the stash in an [diff]/[apply]/[pop] manner and hand-adjust patches. I've had good luck w/ the robustness of the final [pop] against patched code, and the "depth" of my mistake (a missed commit for a logical code change) has been relatively shallow to date. I wonder (off the top of my head): is there such a thing as a diff that has a range, either explicit or logical ? Example: $ fossil stash save -m 'thought 1' ./mfile -start 20 -end 80 $ fossil stash save -m 'thoght 2' ./mfile -start 90 $ fossil stash pop; fossil ci -m 'my cool feature "thought 2"' $ fossil stash pop; fossil ci -m 'my other feature "thought 1"' > And I am not opposed to providing some reasonable > support for that in Fossil. But there needs to be a balance. We > shouldn't waste too much time implementing that capability when there > are other more useful features that could be added instead, and the > mechanism should not get in the way of people who don't want to use it > or even know about it, and it shouldn't be so easy as to encourage > people to use it to their harm. > > -- > 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Select specific changes within files
On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf wrote: > On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp wrote: > >> On 3/20/15, Martin S. Weber wrote: >> ... > > > in itself). So you end up with intermingled changes which one would >> > like to split cleanly. >> > >> The way I deal with this in SQLite is: >> ... > > (2) On the occasions when I mess up and accidentally put unrelated >> changes into the same check-out, I have been known to stash the whole >> thing, then reapply one set of changes, test, commit, then reapply the >> other set of changes, test, and commit again. > > > This (2) might be easier with something like a > "partial/selective/interactive stash" as mentioned by the OP in the bottom > part of his email. > So (2a) would look like: selectively stash the "second" set of changes, > test (thus including the "first" set of changes), commit, stash pop/apply > "second", test, commit > I suppose this would make sense if there are fewer changes to "undo" in the edited code than to "re do" in the reverted code. You can achieve the same result with "fossil snapshot" (which skips the automatic revert), then "fossil gdiff" to selectively "undo" changes. Then edit/build/test/commit what remains. After that, "fossil stash gdiff" to selectively re-apply more changes. Repeat as needed ___ 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] Select specific changes within files
On 2015-03-20 13:04:44, Richard Hipp wrote: > (...) > The way I deal with this in SQLite is: > > (1) Make logically separate changes in separate check-outs so that > they are easy to test and commit separately. (...) That's the sort of flow-interrupting context switch I was referring to on one hand, for myself; I see the usefulness of this approach, also it's very KISS. I like it. I usually do not treat checkouts as transient as this implies, but there's nothing wrong with doing that, considered it does not interrupt you. Maybe having it in mind won't interrupt me next time I stumble over it, I'll wait and see. > (2) On the occasions when I mess up and accidentally put (...) That's the sort of thing that one can do after the fact, i.e., when the housekeeping portion after the productivity burst is coming to take a breather... see more below. > (3) You might also check-in the whole thing into a side branch, then > do multiple partial merges back into the branch you were (...) I can see one doing this when they approach their checkout with a plan they know will create mess. It's good advice. I think in combination, your three approaches actually cover the use-cases I have, when I'm considering the topic of partial commits. I suppose the process of (2) and a partial commit selection would be actually end up being quite similar (in (2) you have more (visual) context but you make the same choices for the most part, i.e., select this, ignore that, ...) Partial commits would offer a line of "defense", of cleaning up and associating metadata with changes. (2) fulfills this role just as well. (1) is good reminder/advice for when the opening is quick. People should be doing (3) for messy stuff anyways :) > Still, there will always be people who are convinced that there is > nothing that can go wrong and what to do a partial commit against > expert advise. I wanted to showcase the potential usefulness of the feature. You're saying you got me covered already. After some consideration I think I agree. So no need for me to ask for and rely on yet-unwritten code. Thanks, -Martin ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp wrote: > On 3/20/15, Martin S. Weber wrote: > ... > in itself). So you end up with intermingled changes which one would > > like to split cleanly. > > > The way I deal with this in SQLite is: > ... (2) On the occasions when I mess up and accidentally put unrelated > changes into the same check-out, I have been known to stash the whole > thing, then reapply one set of changes, test, commit, then reapply the > other set of changes, test, and commit again. This (2) might be easier with something like a "partial/selective/interactive stash" as mentioned by the OP in the bottom part of his email. So (2a) would look like: selectively stash the "second" set of changes, test (thus including the "first" set of changes), commit, stash pop/apply "second", test, commit Imho, the "missing piece" would be "stash" having means to do partial stashing (finer than on file-by-file base). This the would allow to do these "splittings of a mixed up check-outs" a bit easier (including testing "before" committing, no need for "partial commit" then), wouldn't it? Regards Marcel ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 7:56 AM, Abilio Marques wrote: > Yet before that, I knew about stash. But sometimes it was already too late > to simply stash and begin doing some other changes, as both changes were > already in the file. > Never too late to stash. If I decide I need to split out changes already made, I stash the files, then do "fossil stash gdiff" to selectively (re) apply the stashed changes, then build/test/commit. Then "fossil stash gdiff" to apply more of the changes, then build/test/commit. Repeat until all need changes are done. If I think I might later need what I stashed, I can restore it and commit to an appropriate branch. If anything, using the staging area for partial commits just makes it harder to build and test before committing. ___ 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] Select specific changes within files
On 3/20/15, Martin S. Weber wrote: > On 2015-03-20 09:02:32, Richard Hipp wrote: >> (...) >> I'm still having trouble understanding how the partial commit would be >> *useful*, though. > > > Also, ideally you're working in a flow anyways (the deep meditative > state where stuff gets done (tm)); doing housekeeping (stashing here > and there; grouping related changes to single commits so that you can > cleanly test them / undo them as a human without the need for tools such > as unit-testing combined with fossil bisect) is a safe way to kill any > meditative effort (except for real housekeeping, obviously meditative > in itself). So you end up with intermingled changes which one would > like to split cleanly. > The way I deal with this in SQLite is: (1) Make logically separate changes in separate check-outs so that they are easy to test and commit separately. A real-life example of this can be seen at https://www.sqlite.org/src/timeline?c=08958f57 - I was working on the stat4-function branch when I noticed that an unrelated comment needed to be cleaned up, so I checked in the comment fix separately, then continued merrily working away on stat4-function. (2) On the occasions when I mess up and accidentally put unrelated changes into the same check-out, I have been known to stash the whole thing, then reapply one set of changes, test, commit, then reapply the other set of changes, test, and commit again. (3) You might also check-in the whole thing into a side branch, then do multiple partial merges back into the branch you were working on, with appropriate comments on each merge. (To do the partial merge, you merge the whole change, then back out the parts that you don't want for the current partial merge, test and commit, then repeat. Copy/Paste from "fossil diff --tk" gets this done rather efficiently, in my experience.) You can argument that (2) might have been easier with a partial commit. Maybe so; maybe a little easier, but not a huge amount easier. And I would have had to skip the testing step, which might have caused problems in the future such that the total effort (effort to commit plus effort to fix problems caused by the untested commit) is greater than the effort of applying procedure (2) as written. So one can argue that partial commit might save you (a little) effort today, but will end up requiring more work in the long-term. Still, there will always be people who are convinced that there is nothing that can go wrong and what to do a partial commit against expert advise. And I am not opposed to providing some reasonable support for that in Fossil. But there needs to be a balance. We shouldn't waste too much time implementing that capability when there are other more useful features that could be added instead, and the mechanism should not get in the way of people who don't want to use it or even know about it, and it shouldn't be so easy as to encourage people to use it to their harm. -- 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] Select specific changes within files
On Fri, Mar 20, 2015 at 10:26 AM, bch wrote: > I'm still confused about what "complete" or "split" means in the > contexts that I think people are using this -- > > If I accidentally code two different logical thoughts into a single > file -- and so they are "combined", and uncommitted -- why would tools > or facilities to aid making-discrete two different logical ideas be > discouraged, and what precludes testing this separated code ? > I think the problem is not everyone is using "test" exactly the same way. If you are talking about automated testing, it can only happen after committing code. If you are talking about developer testing, yes, you can test code after committing it, but ideally you've made changes, tested them, then committed. The staging mechanism seems to require you to make a commit before testing. With git, not so bad. You can rewrite history as much as you want until you're satisfied. With fossil, this doesn't work. Except that it can work in a similarly functional way (yet less confusing from my perspective) as I outlined in my previous email. -- Scott Robison ___ 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] Select specific changes within files
On 2015-03-20 09:02:32, Richard Hipp wrote: > (...) > I'm still having trouble understanding how the partial commit would be > *useful*, though. Some people like their metadata (i.e. fossil's commit message log) to match up with what they were doing in the files. You go to your file, you begin to work on task A, something comes along, and work on task B gets intermingled with the A changes. You wanna commit with metadata (commit log) that clearly says A was done here, and B was done there. Often enough, it's easy to halt before starting on B, commit (or stash), go on to B, etc. Also, ideally you're working in a flow anyways (the deep meditative state where stuff gets done (tm)); doing housekeeping (stashing here and there; grouping related changes to single commits so that you can cleanly test them / undo them as a human without the need for tools such as unit-testing combined with fossil bisect) is a safe way to kill any meditative effort (except for real housekeeping, obviously meditative in itself). So you end up with intermingled changes which one would like to split cleanly. But fossil is not git, you can't tear your history apart.So you have to make sure the right history gets recorded (forever) in the first place. And we're back at partial committing with usefulness. Regards, -Martin ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 5:56 AM, Abilio Marques wrote: > Neat ideas already popped. Here I copy/paste some fragments of them: > > fossil diff --tk --partial-commit (Then, an automatic "fossil stash" is >> performed where the original modified files are stored. The files left in >> the working area only contain the selected differences) >> > > I personally would like a selective stash. Perhaps one where you can > selectively push some changes (then fossil could proceed to remove them > from the actual files), or selectively pop/apply some changes (but I > imagine this one could get things confusing, specially if used with apply). > Here is the problem with an interactive partial-commit that I see. But first some history: A couple days ago I was convinced I'd found a bug in the merge conflict code. I hadn't, but was confused by a merge conflict in a file where the exact same line was missing (correctly) from two of the three portions of the merge conflict in the source file. I experimented with some changes to try to make things more clear for future me by having the merge conflict include more history. In my one specific test case, it was helpful, but I quickly realized that: - What if the "missing context" came at the beginning of a merge conflict instead of at the end of the merge conflict? By the point fossil identifies the lines that are part of the merge conflict we've already passed up potentially deleted history and it would be quite complex to backup. Not impossible, but very complex. - What if the missing historical context at the end of the merge conflict was more than one line? How to know how much extra history is needed for this one exact file, where this file could be C source, or README, or XML, or JSON, or C++, or any other form of text file? - What if the missing historical context isn't even needed (which is probably often the case)? In that case adding even an extra line could confuse the issue just as much as the missing extra line was confusing me. Note: In my case the missing line was #endif which would have left the merge non-buildable if I only used the merge conflict info to resolve the conflict. I realized that there is no right answer to those questions. The point of the merge conflict is that there was a conflict and a human had to make a decision and all it could do is provide me what it knew about the state of the merge. It is up to the human to take whatever additional remedial tasks (such as diffing baseline against each copy and whatever other analysis is needed). Okay, sorry for that. There is a point, though. An ability to selectively commit just portions of a file implies an ability to differentiate which pieces are needed where. A human can do this. If the idea above (fossil diff --tk --partial-commit) is to allow individual blocks of changes to be selected, then it is too coarse grained for all situations. If it has checkboxes on every changed line, then it might be adequate. Nope, scratch that, it is possible that two changes could impact the same line in different ways, so even a line by line set of checkboxes would be too coarse grained. How about a word by word set of checkboxes? Character by character? These changes could be anything, source code, documentation, data files, html, css, javascript, C, etc, etc. Whatever solution is implemented needs to accommodate all of them, and others not yet mentioned or imagined. If the diff model proposed accommodates all these potential variations, what has been invented is essentially a text editor. I am sympathetic to the idea that you don't *intend* to jumble up changes in a single set of edits and only realize after the fact that you've accomplished exactly that, and thus you want a way to extract the changes into two separate commits / branches / whatever. I think the git model is only appealing at this point because it allows you to rewrite history. You can commit anything you want to a git repo without trepidation because you can always modify it, rebase it, delete it, whatever you want. This doesn't work with fossil due to the immutable history functionality, which is a feature. The fossil version of this workflow would be something along the lines of: 1. You've opened a repo into work area A. 2. You've gone along happily editing for whatever period of time only to realize "dang, I mixed up these two things, I need to separate them". 3. You make a copy of the entire work area A as work area B (perhaps with a fossil open --keep, I'm not sure as I've not tried this myself). 4. In work area A you remove the parts that should only be in work area B and test/commit. 5. In work area B you remove the parts that should only be in work area A and test/commit. Or alternatively: 3. You stash snapshot your current set of changes. 4. You remove one set of changes and test/commit. 5. You stash pop, remove the other set of changes and test/commit. As I understand it, with git you'd do something like: 3. You st
Re: [fossil-users] Select specific changes within files
I'm still confused about what "complete" or "split" means in the contexts that I think people are using this -- If I accidentally code two different logical thoughts into a single file -- and so they are "combined", and uncommitted -- why would tools or facilities to aid making-discrete two different logical ideas be discouraged, and what precludes testing this separated code ? -bch On 3/20/15, Luca Ferrari wrote: > On Fri, Mar 20, 2015 at 2:02 PM, Richard Hipp wrote: >> I agree with Stephan, except to note that some repositories do not >> store code. If you are checking in changes to text documentation, >> then maybe testing is not as important and a partial commit would be >> ok. >> > > I believe it can be evil even in this scenario. > Isolation, in my opinion, must be achieved with branches. And > "complete" commits, as opposed to partial ones, should be done with > merges. > I believe I'm totally misunderstanding, but used to do very small > commits, it does not make much sense to have "partial" commits. Or at > least, I cannot see how my workflow would be better using them. > Moreover, I believe that partial commits, in the form I understand > from this thread, will call for a continuos amend/rebase (are you sure > you will never miss a line in a partial commit?). > > Luca > ___ > 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] Select specific changes within files
On Fri, Mar 20, 2015 at 2:02 PM, Richard Hipp wrote: > I agree with Stephan, except to note that some repositories do not > store code. If you are checking in changes to text documentation, > then maybe testing is not as important and a partial commit would be > ok. > I believe it can be evil even in this scenario. Isolation, in my opinion, must be achieved with branches. And "complete" commits, as opposed to partial ones, should be done with merges. I believe I'm totally misunderstanding, but used to do very small commits, it does not make much sense to have "partial" commits. Or at least, I cannot see how my workflow would be better using them. Moreover, I believe that partial commits, in the form I understand from this thread, will call for a continuos amend/rebase (are you sure you will never miss a line in a partial commit?). Luca ___ 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] Select specific changes within files
Let's forget the GIT staging area, I believe most of us, fossil users, have proven that is not needed at all. Years and years committing without staging, that proves is not needed ;) On Mar 20, 2015 10:51 AM, "Kevin Greiner" wrote: > On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques >> wrote: >> I personally would like a selective stash. > > > Yes, I would find selective stash save/apply useful. > > But I see the dangers of partial commit of git's staging area. I admit, > I've abused that myself to commit a comment or documentation typo without > compiling or testing. > > >> Perhaps one where you can >> selectively push some changes (then fossil could proceed to remove them >> from the actual files), or selectively pop/apply some changes (but I >> imagine this one could get things confusing, specially if used with >> apply). > > > I've read that git has an interactive mode [1] that allows the user to > stage specific parts or changes within a single file. However, I've only > used Atlassian's SourceTree tool to interact with git's staging area. The > GUI makes it simple to select chunks to include or exclude. > > 1 - > http://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging#Staging-Patches > > ___ > 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] Select specific changes within files
> > On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques > wrote: > I personally would like a selective stash. Yes, I would find selective stash save/apply useful. But I see the dangers of partial commit of git's staging area. I admit, I've abused that myself to commit a comment or documentation typo without compiling or testing. > Perhaps one where you can > selectively push some changes (then fossil could proceed to remove them > from the actual files), or selectively pop/apply some changes (but I > imagine this one could get things confusing, specially if used with > apply). I've read that git has an interactive mode [1] that allows the user to stage specific parts or changes within a single file. However, I've only used Atlassian's SourceTree tool to interact with git's staging area. The GUI makes it simple to select chunks to include or exclude. 1 - http://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging#Staging-Patches ___ 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] Select specific changes within files
Yes, that's my vision of it. I've come to several situations in which feature A and feature B share the same file. I then proceed to remove all the code from feature B, run the tests for the A, pass them, then commit. Then apply back the lines from feature B, retest, pass, and commit. Actually in those cases, sometimes I can swap the order: first go with feature B, as I know feature A it's not compete yet, so I "stash" the A, proceed to B to deliver it quickly, then switch to my lower priority A. Once I worked in a company with continuous integration, and perhaps they were doing it wrong, but you actually committed into a specific test branch in to get the code to be tested. In my personal life, I do a lot of embedded code for microcontrollers, so automated tests are not available. I test my code by hand, it seems to pass, yet contains bugs. Even for Qt I work like that. Another case I could use it a lot is in documents, as Richard said. On Mar 20, 2015 10:05 AM, "bch" wrote: > Can we define partial commit ? > > Are we talking about when I , , and then realize > that I've got two features' worth of new material and would like to > separate them so that Feature B is held back, Feature A is applied > (and yes, tested, etc., etc) and committed, then Feature B is applied > (tested, etc.) and committed ? > > Or am I misunderstanding ? > > -bch > > > On 3/20/15, Richard Hipp wrote: > > On 3/20/15, Stephan Beal wrote: > >> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques > >> wrote: > >> > >>> I personally would like a selective stash. Perhaps one where you can > >>> selectively push some changes (then fossil could proceed to remove them > >>> from the actual files), or selectively pop/apply some changes (but I > >>> imagine this one could get things confusing, specially if used with > >>> apply). > >>> ... > >>> What are your opinions? Is this useful? Is this powerful? What would > your > >>> approaches be? > >>> > >> > >> IMO it's inherently evil because it promotes checking in untested > subsets. > >> Automated tests require a full, valid tree. Checking in a part of a > change > >> may well lead to code which runs on your machine but doesn't run on > >> remotes > >> (continuous integration systems or other users). > >> > > > > I agree with Stephan, except to note that some repositories do not > > store code. If you are checking in changes to text documentation, > > then maybe testing is not as important and a partial commit would be > > ok. > > > > I'm still having trouble understanding how the partial commit would be > > *useful*, though. > > -- > > 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 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] Select specific changes within files
Can we define partial commit ? Are we talking about when I , , and then realize that I've got two features' worth of new material and would like to separate them so that Feature B is held back, Feature A is applied (and yes, tested, etc., etc) and committed, then Feature B is applied (tested, etc.) and committed ? Or am I misunderstanding ? -bch On 3/20/15, Richard Hipp wrote: > On 3/20/15, Stephan Beal wrote: >> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques >> wrote: >> >>> I personally would like a selective stash. Perhaps one where you can >>> selectively push some changes (then fossil could proceed to remove them >>> from the actual files), or selectively pop/apply some changes (but I >>> imagine this one could get things confusing, specially if used with >>> apply). >>> ... >>> What are your opinions? Is this useful? Is this powerful? What would your >>> approaches be? >>> >> >> IMO it's inherently evil because it promotes checking in untested subsets. >> Automated tests require a full, valid tree. Checking in a part of a change >> may well lead to code which runs on your machine but doesn't run on >> remotes >> (continuous integration systems or other users). >> > > I agree with Stephan, except to note that some repositories do not > store code. If you are checking in changes to text documentation, > then maybe testing is not as important and a partial commit would be > ok. > > I'm still having trouble understanding how the partial commit would be > *useful*, though. > -- > 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Select specific changes within files
On Fri, Mar 20, 2015 at 3:35 PM, bch wrote: > Can we define partial commit ? > > Are we talking about when I , , and then realize > that I've got two features' worth of new material and would like to > separate them so that Feature B is held back, Feature A is applied > (and yes, tested, etc., etc) and committed, then Feature B is applied > (tested, etc.) and committed ? > i was referring specifically (but in unfortunately vague terminology) to partial-file commits. i.e. committing chunks 3 and 4 out of 7 changes in the same file. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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] Select specific changes within files
On 3/20/15, Stephan Beal wrote: > On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques > wrote: > >> I personally would like a selective stash. Perhaps one where you can >> selectively push some changes (then fossil could proceed to remove them >> from the actual files), or selectively pop/apply some changes (but I >> imagine this one could get things confusing, specially if used with >> apply). >> ... >> What are your opinions? Is this useful? Is this powerful? What would your >> approaches be? >> > > IMO it's inherently evil because it promotes checking in untested subsets. > Automated tests require a full, valid tree. Checking in a part of a change > may well lead to code which runs on your machine but doesn't run on remotes > (continuous integration systems or other users). > I agree with Stephan, except to note that some repositories do not store code. If you are checking in changes to text documentation, then maybe testing is not as important and a partial commit would be ok. I'm still having trouble understanding how the partial commit would be *useful*, though. -- 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] Select specific changes within files
On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques wrote: > I personally would like a selective stash. Perhaps one where you can > selectively push some changes (then fossil could proceed to remove them > from the actual files), or selectively pop/apply some changes (but I > imagine this one could get things confusing, specially if used with apply). > ... > What are your opinions? Is this useful? Is this powerful? What would your > approaches be? > IMO it's inherently evil because it promotes checking in untested subsets. Automated tests require a full, valid tree. Checking in a part of a change may well lead to code which runs on your machine but doesn't run on remotes (continuous integration systems or other users). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Select specific changes within files
After a yesterday's email entitled “is this a crazy idea?” meant to ask about a shim ended in a really interesting discussion about select specific changes to files, I think we could give that idea a chance to live (just as an idea, for the time being). I've personally gone through times where I've needed it. And yes Mr. Hipp, now I know about multiple check-outs, thanks for that one. Yet before that, I knew about stash. But sometimes it was already too late to simply stash and begin doing some other changes, as both changes were already in the file. That normally means a kinda complicated/frustrating/error prone process (ok, is not the end of the world, yet, would be lovely to have an easier, safer way) to split the two changes. I guess everyone must agree with me on this. If you catch the need for the split early on, is a trivial thing, but if you've gone until the end of at least one of the changes, splitting is not that easy anymore. So having the means to “automate” that splitting process seems to be great. I use the word “seems”, as I've never used such a thing, so I can't actually give an opinion on usefulness. Neat ideas already popped. Here I copy/paste some fragments of them: AFAIK with git staging you can select specific changes in a single file as > well, to commit only a sub-set of changes in that file. > > *That* would be neat to have -- I've heard of it in git, but not explored > it. > > Third, while splitting commits (where you accidentally mashed multiple > things together that you later realize should be separated) is a very > relevant feature > > This does not require a staging area. Darcs, for example, had such > selective commits since its inception (in fact, it was and is the default > mode of operation for Darcs, for better or worse). > > A stash with abilites like "git add --interactive" to stash parts within a > file is the way to go IMO. > > fossil diff --tk --partial-commit (Then, an automatic "fossil stash" is > performed where the original modified files are stored. The files left in > the working area only contain the selected differences) > I personally would like a selective stash. Perhaps one where you can selectively push some changes (then fossil could proceed to remove them from the actual files), or selectively pop/apply some changes (but I imagine this one could get things confusing, specially if used with apply). I've never played with Darcs nor any other tool that provides this functionality, except for GIT, and I started playing with that function yesterday. It seems that GIT gives you the chance to select the changes by editing the unified patch on your favorite text editor (I guess someone mentioned that in his workflow for this situation, he did something similar, but manually). More ideas on this? What are your opinions? Is this useful? Is this powerful? What would your approaches be? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
