Re: [fossil-users] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
* Joel Bruick j...@joelface.com [20140606 06:55]: Richard Hipp wrote: On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com mailto:n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com mailto:estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. I have different reasons for opposing the ability to checking individual lines of a file, and I'd like to get Nico's feedback: The reason you should never do a partial check-in of a file is because you clearly have not tested that partial change. And you should always test your code before you commit. Especially when committing to trunk. I agree with this, but Git does make testing your staged changes relatively easy. You can call git stash save --keep-index to stash only your unstaged changes, run your tests, commit, then call git stash pop and continue working. With that said, I think that adding a way to stash partial changes to files would be enough for what most people actually need from a staging area (pulling out unrelated changes so they can be committed separately). Seconded, this would simplify certain workflows a lot (the painful alternative has already been pointed out). A command line implementation of what tortoisehg offers as shelve would be awesome. keep up the good work -- pica ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Nico Williams n...@cryptonector.com writes: I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. You put it very nicely together!! I also want the power of SQL for history, and so on. +1 Sincerely, Gour -- Many, many births both you and I have passed. I can remember all of them, but you cannot, O subduer of the enemy! ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Hey Nico -- Some thought-provoking comments. Thanks. -bch On 6/7/14, Gour g...@atmarama.net wrote: Nico Williams n...@cryptonector.com writes: I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. You put it very nicely together!! I also want the power of SQL for history, and so on. +1 Sincerely, Gour -- Many, many births both you and I have passed. I can remember all of them, but you cannot, O subduer of the enemy! ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Fri, Jun 6, 2014 at 10:51 PM, Nico Williams n...@cryptonector.com wrote: On Saturday, June 7, 2014, Andy Bradford amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org wrote: Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. This workflow certainly seems like a lot of time spent playing with the tool and less time working on code. Do Git users typically make such large commits? Why don't they just use branches to separate different lines (as in tracks) of development rather than bundling a bunch of unrelated checkins all at once? Not git users. Engineers who work on codebases with maintenance releases. For example: Solaris, Windows, ... but also a number of smaller projects, like MIT Kerberos, Heimdal, and so on. When you have a bug that needs to be fixed in older releases, you want to be able to cherry-pick it, and sometimes you don't know this until after you've integrated a fix for it in the main trunk. This is one reason that clean history is appreciated. And when investigating a bug it's also nice to be able to look back through the history and understand what was done (as opposed to how a programmer got there, which is ticket/comment fodder). (For years i worked on codebases where we used Teamware -an ancient, ancient VCS now- and we'd worked out how to implement a rebase-heavy workflow, in a team of thousands. This isn't about git. Git just happens to be the first modern VCS that made this workflow possible with little pain. If i had to use Fossil in such a workflow, I'd do the sorts of things i was used to doing with Teamware, as meantioned earlier in this thread.) The first case is easy to drop: never keep maintenance releases. Mostly that's the right thing to do, especially if in the process you can train your users to stay on the bleeding edge instead of worrying about upgrading with every critical security bugfix. But it's not always possible or easy to do this, or perhaps having older releases on maintenance is part of the vendor's business model. Either way, there's still the matter of clean, comprehensible history -- reasonable people can disagree about this, of course, and precisely because of that there are codebases where the gatekeeprs force a rebase heavy workflow on contributors. I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. I also want the power of SQL for history, and so on. So I can get this neither from Fossil nor git. Well, so be it. I won't be adding writing a VCS to my bucket list, we each have our priorities, and I wouldn't likely do a very good job of it; at most I will pursue minor extensions (or hooks) to git to get me the query power and recovery semantics I need. I think it best now for me to let this poor dead horse be. Thanks for listening and engaging me on this subject, and my apologies for taking so much of your time (especially since I love SQLite and want to do nothing to slow down your efforts there), Would not adding an incremental stash meet this need? In fact I think that an incremental stash would actually not only meet the need but be more flexible and easier to work with than the index approach because you can use update to take a snapshot and quickly and easily apply it to another branch. Having read though this thread again I really think that a way to work with stashes incrementally would be extremely useful. It might be too disruptive a change but merely making the fossil stash snapshot default to incremental would work well. Alternatively add a switch: fossil stash snapshot -inc 3 # save the changes made from snapshot 3 to now as a new snapshot Matt Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. Also, one may want to break up a commit into: code, test, doc updates that go together, in which case the test may not pass for one of those commits by intention. ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Fri, Jun 6, 2014 at 7:45 PM, Nico Williams n...@cryptonector.com wrote: I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. Also, one may want to break up a commit into: code, test, doc updates that go together, in which case the test may not pass for one of those commits by intention. This whole discussion speaks to one of the key philosophical differences between Git and Fossil, which is that Fossil strives to record exactly what you did whereas Git strives to record what you should have done. -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. This workflow certainly seems like a lot of time spent playing with the tool and less time working on code. Do Git users typically make such large commits? Why don't they just use branches to separate different lines (as in tracks) of development rather than bundling a bunch of unrelated checkins all at once? Andy -- TAI64 timestamp: 40005392a236 ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Saturday, June 7, 2014, Andy Bradford amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org wrote: Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. This workflow certainly seems like a lot of time spent playing with the tool and less time working on code. Do Git users typically make such large commits? Why don't they just use branches to separate different lines (as in tracks) of development rather than bundling a bunch of unrelated checkins all at once? Not git users. Engineers who work on codebases with maintenance releases. For example: Solaris, Windows, ... but also a number of smaller projects, like MIT Kerberos, Heimdal, and so on. When you have a bug that needs to be fixed in older releases, you want to be able to cherry-pick it, and sometimes you don't know this until after you've integrated a fix for it in the main trunk. This is one reason that clean history is appreciated. And when investigating a bug it's also nice to be able to look back through the history and understand what was done (as opposed to how a programmer got there, which is ticket/comment fodder). (For years i worked on codebases where we used Teamware -an ancient, ancient VCS now- and we'd worked out how to implement a rebase-heavy workflow, in a team of thousands. This isn't about git. Git just happens to be the first modern VCS that made this workflow possible with little pain. If i had to use Fossil in such a workflow, I'd do the sorts of things i was used to doing with Teamware, as meantioned earlier in this thread.) The first case is easy to drop: never keep maintenance releases. Mostly that's the right thing to do, especially if in the process you can train your users to stay on the bleeding edge instead of worrying about upgrading with every critical security bugfix. But it's not always possible or easy to do this, or perhaps having older releases on maintenance is part of the vendor's business model. Either way, there's still the matter of clean, comprehensible history -- reasonable people can disagree about this, of course, and precisely because of that there are codebases where the gatekeeprs force a rebase heavy workflow on contributors. I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. I also want the power of SQL for history, and so on. So I can get this neither from Fossil nor git. Well, so be it. I won't be adding writing a VCS to my bucket list, we each have our priorities, and I wouldn't likely do a very good job of it; at most I will pursue minor extensions (or hooks) to git to get me the query power and recovery semantics I need. I think it best now for me to let this poor dead horse be. Thanks for listening and engaging me on this subject, and my apologies for taking so much of your time (especially since I love SQLite and want to do nothing to slow down your efforts there), Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:08 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Fossil allows you to commit a subset of files (by listing the files on the fossil commit command line) but there is no mechanism for committing a subset of lines within a single file. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com: On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ 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 -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
drh Fossil allows you to commit a subset of files (by listing the files on the fossil commit command line) but there is no mechanism for committing a subset of lines within a single file. That, and there _are_ branches/tags which are encouraged to be used... my prev comment was for the case where a single file gets two-thoughts worth of changes (subset of lines). For subsets of lines (assume we want two logical commits), I head to my editor, tease out logical section1 - tmp file. fossil stash save -m logical thought temp1 ./file-of-interest; re-enter tmp.file - file-of-interest; fossil ci -m description of logical thought ./file-of-interest; fossil stash pop [edit if necessary]; fossil ci -m description of other logical thought ./file-of-interest If one is using feature branches though, you'll be prompted to save as you switch between them, keeping your fossil repo up-to-date. -bch On 6/5/14, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 11:08 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Fossil allows you to commit a subset of files (by listing the files on the fossil commit command line) but there is no mechanism for committing a subset of lines within a single file. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com: On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ 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 -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 10:36 AM, B Harder brad.har...@gmail.com wrote: drh Fossil allows you to commit a subset of files (by listing the files on the fossil commit command line) but there is no mechanism for committing a subset of lines within a single file. That, and there _are_ branches/tags which are encouraged to be used... my prev comment was for the case where a single file gets two-thoughts worth of changes (subset of lines). For subsets of lines (assume we want two logical commits), I head to my editor, tease out logical Key words there: tease out. You have to stare at diffs and do/undo part of the change by manual application of diffs. Compare to SourceTree's interface to the index: https://www.google.com/search?q=sourcetree+stage+hunk+screenshotstbm=ischtbo=usource=univsa=Xbih=663 Or git add -e or -p, or hg record. SourceTree's GUI interface lets you: - stage/discard/neither by hunk - stage/discard/neither specific lines in hunks - edit hunk lines to be staged That's also what git add -e lets you do. It's just much easier to disentangle large diffs this way than with manual teasing out via $EDITOR. section1 - tmp file. fossil stash save -m logical thought temp1 ./file-of-interest; re-enter tmp.file - file-of-interest; fossil ci -m description of logical thought ./file-of-interest; fossil stash pop [edit if necessary]; fossil ci -m description of other logical thought ./file-of-interest I know how to do this. I did this for many, many years before the advent of git, and my learning git add -p/-e. Even a grumpy systems guy whose every command-line is a script... can learn to love not having to do error-prone operations like this in such a manual way. I could never teach my non-programmer spouse to do what you do to work around Fossil's lack of anything like hg record or the git index, but with SourceTree's interface to git she does this every day without breaking a sweat. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Using stash and doing update then commits to appropriate branches along mostly addresses the need to split out changes from a single editing session. The one thing it cannot do is easily accommodate a mix of changes in a single file. That said I think I disagree that this is really needed. In git it appears to me that if you didn't have the foresight to add each of a series of changes as you worked then you have the same effort in teasing out one change from another as you would in fossil. I think the rough equivalent to git add is fossil stash snapshot. I could see a gui or script that could take all the hunks from a changed file and store them in individual stashes being useful. In short implementing the SourceTree mechanism should be possible in fossil using stash save and or snapshot ... well, maybe ... Illustration: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: fossil stash save -m saving changes A, B, C and D as a single stash for safeties sake fossil update trunk fossil stash apply A; fossil commit -m committing A to trunk fossil stash apply B; fossil update b-d; fossil commit -m Moved change B to branch b-d and committed it # A is applied to trunk and B to b-d but now it gets ugly fossil update original-refid fossil stash apply C fossil merge --backout refid-for-change-b fossil merge --backout refid-for-change-a fossil commit -m Applied A+B+C-B-A fossil update c-d fossil commit -m committing C to c-d and so forth The inability to do an incremental stash makes this difficult for anything other than simple use cases. Suggestion: consider adding a mechanism to either apply a delta from two stashes to the working set or a way to do an incremental stash. Then the methodology of using stash to replace the git index should work. Editorial: I might occasionally use such a feature but I have very seldom felt any need to do this complex messing around *after* coding. Usually I just realize that a change belongs on a different branch and do update to that branch, commit, update back to where I was. I.e. use a little discipline in place of flexibly complexity. For the once in a blue moon where I goof and put a change in the wrong place I use do a couple of cherrypicks to move the change to the appropriate branch. On Thu, Jun 5, 2014 at 9:40 AM, Nico Williams n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 10:36 AM, B Harder brad.har...@gmail.com wrote: drh Fossil allows you to commit a subset of files (by listing the files on the fossil commit command line) but there is no mechanism for committing a subset of lines within a single file. That, and there _are_ branches/tags which are encouraged to be used... my prev comment was for the case where a single file gets two-thoughts worth of changes (subset of lines). For subsets of lines (assume we want two logical commits), I head to my editor, tease out logical Key words there: tease out. You have to stare at diffs and do/undo part of the change by manual application of diffs. Compare to SourceTree's interface to the index: https://www.google.com/search?q=sourcetree+stage+hunk+screenshotstbm=ischtbo=usource=univsa=Xbih=663 Or git add -e or -p, or hg record. SourceTree's GUI interface lets you: - stage/discard/neither by hunk - stage/discard/neither specific lines in hunks - edit hunk lines to be staged That's also what git add -e lets you do. It's just much easier to disentangle large diffs this way than with manual teasing out via $EDITOR. section1 - tmp file. fossil stash save -m logical thought temp1 ./file-of-interest; re-enter tmp.file - file-of-interest; fossil ci -m description of logical thought ./file-of-interest; fossil stash pop [edit if necessary]; fossil ci -m description of other logical thought ./file-of-interest I know how to do this. I did this for many, many years before the advent of git, and my learning git add -p/-e. Even a grumpy systems guy whose every command-line is a script... can learn to love not having to do error-prone operations like this in such a manual way. I could never teach my non-programmer spouse to do what you do to work around Fossil's lack of anything like hg record or the git index, but with SourceTree's interface to git she does this every day without breaking a sweat. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. Sometimes I don't realize that A is really two separable changes worth separating. Or maybe I don't think they are worth separating but my upstream does. Or maybe I'm the upstream and it's a contributor that I am asking to split up A. Counting on foresight is not a good plan :) The main reasons I can think of to not have an index are that one either really is so careful that they have such foresight, and/or one does not [have to] care to disentangle changes. Fossil and SQLite3 seem to only move forwards: there are no maintenance release branches, because there are no maintenance releases. Need a bug fixed? Get on the bleeding edge. That works fine for some projects, in which case Fossil will do. Otherwise one must very manually disentangle changes or not use Fossil. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. I have different reasons for opposing the ability to checking individual lines of a file, and I'd like to get Nico's feedback: The reason you should never do a partial check-in of a file is because you clearly have not tested that partial change. And you should always test your code before you commit. Especially when committing to trunk. -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 7:58 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. I have different reasons for opposing the ability to checking individual lines of a file, and I'd like to get Nico's feedback: The reason you should never do a partial check-in of a file is because you clearly have not tested that partial change. And you should always test your code before you commit. Especially when committing to trunk. Ah, I forgot to mention how I deal with that: I abuse (but Fossil could do this differently) git rebase -i, adding an exec line after each commit to run tests. I say abuse because the rebase is a no-op as far as history is concerned. This is standard use of rebase in git-land though, and I won't fault anyone for thinking this should be done with a less scary-sounding command. In Fossil terms that would be like checking out each commit in the series to be integrated/pushed upstream, run tests, then checkout the next commit. Wrap that in a script and there you go. It is true that wanting clean history upstream does lead to something of an interactive-rebase-test loop. That's the price of clean history. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I'm not Nico, but allow me answer that as well. When I was learning to use git, my teacher told me: When you have a set of changes where a peace of code requires another peace, you must commit all that together. But if you have a change that doesn't have any dependeces, you should commit that change alone. And, well, the same reason you can use to not allow partial chink-in of a file can be used to not allow commits on a set of files. So, if we have commit what we tested, we alwayes must to commit all the changes in all the files. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-05 21:58 GMT-03:00 Richard Hipp d...@sqlite.org: On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. I have different reasons for opposing the ability to checking individual lines of a file, and I'd like to get Nico's feedback: The reason you should never do a partial check-in of a file is because you clearly have not tested that partial change. And you should always test your code before you commit. Especially when committing to trunk. -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I'm not Nico, but allow me answer that as well. When I was learning to use git, my teacher told me: When you have a set of changes where a peace of code requires another peace, you must commit all that together. But if you have a change that doesn't have any dependeces, you should commit that change alone. Where to draw the line is a bit of an art. The programmer (and code reviewers) have to judge what changes are independent in some way and which are too interrelated to be separable. This is true. And, well, the same reason you can use to not allow partial chink-in of a file can be used to not allow commits on a set of files. So, if we have commit what we tested, we alwayes must to commit all the changes in all the files. That's the same point that DRH made, and so it gets the same answer: you must test each commit. And there's a way to with git, and surely that can also be scripted for Fossil (or written right into Fossil). And yes, every time your individual commits fail to pass tests you have to go rebase. So there is another reason to not want an index: if you get it, you'll inexorably also want rebase functionality, including interactive rebase. And if you hate (or misunderstand) rebase, you'll then not want an index. I hadn't considered this. Of course, I like rebase -- no surprise there. And the Fossil community evidently hates rebase. I suspect I can't sell you on rebase, even though I'd like to, and even though I think a dislike of rebase results mostly from misunderstanding what it is and how to use it. (As opposed to a dislike of having to rebase, which is what happens when an upstream asks a contributor to rewrite their history -- more homework - dislike.) Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Richard Hipp wrote: On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com mailto:n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com mailto:estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. I have different reasons for opposing the ability to checking individual lines of a file, and I'd like to get Nico's feedback: The reason you should never do a partial check-in of a file is because you clearly have not tested that partial change. And you should always test your code before you commit. Especially when committing to trunk. I agree with this, but Git does make testing your staged changes relatively easy. You can call git stash save --keep-index to stash only your unstaged changes, run your tests, commit, then call git stash pop and continue working. With that said, I think that adding a way to stash partial changes to files would be enough for what most people actually need from a staging area (pulling out unrelated changes so they can be committed separately). ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com wrote: Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. My view is that the Git staging area (I really dislike the use of the word index in that context) merely makes Git more difficult for people to understand and complicates the interface without adding any new capability. The staging area is another element of state on a check-out. It is one more thing that the developer must keep in mind. Better to minimize the amount of mind-space required for the VCS in order to leave as much mind-space available to the application as possible. Mind-space is a finite resource. Use it wisely. The staging area complicates the interface. Instead of just a diff between the current check-out and the most recent check-in, now you have to add syntax for a diff between the checkout and the staging area and a diff between the staging area and the most recent check-in. Multiply that by as many commands as you have that involve both the repository and the current check-out. Does undo/redo effect the staging area? What if you update in order to pull in changes made by a collaborator before you commit - how does that effect the staging area? How does the staging area interact with the stash? If you are making a change in one branch and decide you'd really rather have that change in a different branch (or you just happen to discover that you were mistakenly on the wrong branch - which is the usual reason this comes up for me) and you move all your changes to a different branch prior to check-in, does your staging area move with you or not? Thousands of details like this need to be considered. And all of these details and complications and the associated mental clutter can be quickly and easily eliminated simply by omitting the staging area. My understanding is that the Git staging area arose as part of the implementation showing through into the interface. In Git-speak, it is plumbing that is visible from the porcelain. It is a misfeature. My readings on the matter suggest that most people agree with me on that point. Please keep all thoughts of a staging area far, far away from Fossil. -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com wrote: Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. My view is that the Git staging area (I really dislike the use of the word index in that context) merely makes Git more difficult for people to understand and complicates the interface without adding any new capability. I felt it was a power feature that made my power user life better. Then I showed my wife how to use SourceTree on OS X. I had figured that I'd never show her the index. ETOOHARD I thought. Until something came up where she needed to discard some changes and keep others she had made to a file. SourceTree's GUI interface to the index turns out to be very natural and easy to you. I couldn't believe it, but she picked it up immediately even though she'd never before used git and I'd never thought of how to build a UI to the index. In retrospect the thing is this: at a CLI level, yes, the index requires that users know how do deal with and even edit patch chunks in order to make powerful use of it, and for most users that's just a lot of detail. But in a GUI it turns out that the index can be made a very easy to use feature. The staging area is another element of state on a check-out. It is one more thing that the developer must keep in mind. Better to minimize the amount of mind-space required for the VCS in order to leave as much mind-space available to the application as possible. Mind-space is a finite resource. Use it wisely. The staging area complicates the interface. Instead of just a diff between the current check-out and the most recent check-in, now you have to add syntax for a diff between the checkout and the staging area and a diff between the staging area and the most recent check-in. Multiply that by as many commands as you have that involve both the repository and the current check-out. Does undo/redo effect the staging area? What if you update in order to pull in changes made by a collaborator before you commit - how does that effect the staging area? How does the staging area interact with the stash? If you are making a change in one branch and decide you'd really rather have that change in a different branch (or you just happen to discover that you were mistakenly on the wrong branch - which is the usual reason this comes up for me) and you move all your changes to a different branch prior to check-in, does your staging area move with you or not? Thousands of details like this need to be considered. And all of these details and complications and the associated mental clutter can be quickly and easily eliminated simply by omitting the staging area. My understanding is that the Git staging area arose as part of the implementation showing through into the interface. In Git-speak, it is plumbing that is visible from the porcelain. It is a misfeature. My readings on the matter suggest that most people agree with me on that point. Please keep all thoughts of a staging area far, far away from Fossil. -- 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Thus said Richard Hipp on Wed, 04 Jun 2014 14:34:31 -0400: It clearly would not work for me. As as an amateur user of Git, Git wasn't working for me---perhaps this is simply due to misunderstanding ``core'' features of Git. At any rate, thanks to Git I discovered Fossil and have been pleased with the sanity of its design. It seems that whatever I've wanted to do with Git was always easier and simpler to do with Fossil. I'm not, however, a power user and perhaps that is why Git is not my preferred tool. This doesn't mean Fossil is perfect or a perfect fit in all cases, but having used Git, Hg, Darcs, and Fossil, I definitely prefer Fossil. Of course, Git doesn't have anything like fossil all changes (AFAIK), so maybe that is why nobody has noticed how annoying the staging area might be. I've always thought the ``staging'' area was messy, even before I knew about Fossil---again, I'm no Git expert, just making some observations. Andy -- TAI64 timestamp: 4000538f6bd0 ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com: On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I've heard git allows this, and occasionally wished for it. As it stands currently, it's not possible with fossil. There is a degree of freedom in this regard using the fossil stash, though, which can be used with some file jigging to separate two (or more?) logical ideas that one wants committed discretely. Otherwise, fossils workflow really does encourage the (highly regarded) tenet commit early, commit often. On Jun 4, 2014 8:09 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Alysson Gonçalves de Azevedo Anarcho-syndicalism is a way of preserving freedom. - Monty Python 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com: On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ 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
