Re: [fossil-users] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 11:10:17PM +0100, Joerg Sonnenberger wrote: On Wed, Dec 15, 2010 at 10:50:52PM +0100, Lluís Batlle i Rossell wrote: On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. I prefer the current fossil undo option (with later commit to a branch), and I don't like much those automatic merges done directly, unless they are optional. The trouble with fossil undo is that it throws away the state at some point, e.g. it very volatile and I wouldn't trust it with my data. There is fossil redo, that should put the working directory in the same state as before the undo (regardless of any later changes after the undo). Is it? Automatic merge + commit should definitely be optional behavior. It might make sense to use it as default and fall back to manual merging otherwise. The fossil undo + new branch, for those who believe in saving as much as possible in the history of the file tree, even encourages the public resolution of the merge. For those not wanting to save that publicly, those can even use -private. I would prefer to know in advance whether I can merge without problems or not. Problems against the base revision, not the working copy. This is important to decide whether I have to get a new working copy to do the merge, especially when working on a private branch. I think the fossil 'trunk' knows, whether conflicts come from the working directory or the ckecked out version. The summary after 'merge' could indicate: X conflicts with the local changes, Y conflicts with the checked out version. ___ 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] Stash. Was: How should Fossil handle this merge conflict...
To this point all my fossil usage is mostly-solo, whereas I've been using git on small teams. So when I said I miss it from git, I more properly meant it really comes in handy in my usage of git, and I know fossil doesn't have it, and if I were using fossil in the same contexts as I'm using git, what would I do without it?. I was thinking I would need stash if I were using fossil in a team, but I'm now pretty well convinced that I would need stash only if fossil weren't fossil. However, I've never yet used commit --private. I'm not sure whether it would meet my needs or not. My git workflow when pulling updates from my teammates often goes like this: $ git stash $ git pull # look around at what changed, make sure everything I'm interfacing with still works correctly $ git stash pop Granted that fossil will allow `fossil update` even if I don't commit first, still I think I would often want to use a workflow like the above. How does that look in fossil? My best guess is: $ fossil commit --private $ fossil update previous-branch-name # look around ... $ fossil merge private That's not quite as smooth as the git version, and it requires more attention--e.g., I actually updated to the wrong branch when I tried it out just now, forgetting that I was on 'experimental' instead of trunk in the repo I used before I tried it. And now my working copy and repo are in the desired state, except that foo.txt I added is ADDED_BY_MERGE instead of just ADDED, and I've got a private leaf still hanging around. I can live with those, but for once I think the git command is well named: I use it when I want to 'stash' some stuff away for a bit, then bring it back out again. I don't mean it to be a history event, much less one that appears picked out in gold on my timeline--I'm just shoving some stuff aside on my work table and taking it back out again. If I ignore that private branch and later do the same thing again, will everything still work well? Or should I close the existing private branch first (which requires bringing up the gui and at least 4 clicks)? In tentative conclusion, I think `git stash` really does offer something that isn't convenient to do in fossil, but I doubt it's the number one most important thing to add, and I could accept that it might be more complexity than is worthwhile. BTW, I just noticed that there's `fossil merge --backout`. That's not related to this, but it's cool. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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] Stash. Was: How should Fossil handle this merge conflict...
Hi, I'll say a few things since I was one of those who said git stash in a post :) git stash, I think, is not a necessity but a convenience. There is nothing that you can do with git stash that you can't do with branches. Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. One way to look at the git stash is as a private infinite undo tree. Despite the equivalence of actions of the scm systems, my mind thinks differently with git stash vs any step requiring undo. With stash, it is very obvious to me that absolutely nothing is lost, not even temporarily. If there were infinite undo in fossil, thoughts of disaster can be put to rest very easily. However, with only one level of undo, I don't feel comfortable about relying on undo to not lose work. Sometimes I type commands mechanically and so can't recall what exactly fossil undo will do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a I'd never used commit --private, so I just tried it. After the commit, the state of the checkout is the latest code. Whereas after a stash, the state of the checkout is that of the code *before* your changes. So a stash is a commit followed by a checkout of the earlier version. Again .. that stash combines the two steps in one command is a convenience, not a necessity. As for scenario (3), you're right. Fossil doesn't need stash to do this. Regards, -Kumar On Wed, Dec 15, 2010 at 9:09 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: It would be nice to have something like `git stash`, too. Probably the biggest thing I miss from git. I've been reading up on git-stash to see if Fossil needs a similar feature. So far I don't see the need, since stash doesn't do anything that Fossil doesn't already handle more or less automatically. Please enlighten me if I'm missing something obvious Several cases where the git-stash manpage and other resources recommend using git-stash are shown below, together with how you would do the same thing in Fossil (without a stash). Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a private unpushable branch to store your incomplete change. I don't see how git-stash is any easier than fossil commit -private. In fact, it seems that commit -private is a little easier since it does not require learning a new mechanism (stash versus commit) but rather just a variation on an existing mechanism (commit) which presumably you already know very well. Scenario (3): You start out making changes but later decide that you want to put those changes on a branch, so you git-stash, then git-branch-new to create the new branch, then git-stash-pop, then git-commit. In Fossil, all that extra work is not necessary. You can commit to a branch at any time simply by adding the --branch argument to the fossil commit command line. And, you can even move a check-in that is already committed into a new or different branch using the check-in-edit feature of the fossil ui command. Fossil treats all check-ins as belonging to a single global DAG. Branches are designated using tags, which can be changed and rearranged after-the-fact. Git, on the other hand, appears to keep a separate DAG for each branch, meaning that checkins cannot be so easily move from one branch to another, necessitating tricks like the use of stash. So in summary - Fossil appears to already do everything that git-stash does and do it at least as
Re: [fossil-users] Stash. Was: How should Fossil handle this merge conflict...
On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.comwrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. An alternative idea would be think about it in terms of a patch queue. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Dec 15, 2010, at 16:53 , Joerg Sonnenberger wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.comwrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. An alternative idea would be think about it in terms of a patch queue. Actually what I do is (I install fossil as fl): 1) work freely on my big change, committing atomic changes fl commit --private fl commit --private [...] fl commit --private 2) prepare to make a real commit fl up trunk fl merge private 3) make sure everything works as expected, commit to the world fl commit This feels intuitive and does not leave space for disaster. Furthermore, at step 3 you can see an aggregated diff of the final shape of your big change. And yes, I think of it as a patch queue. How would a stash add value? Apart from the fact, that you have to clone to a new repo to get rid of old private commits. Kind regards, Remigiusz Modrzejewski ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 05:14:08PM +0100, Remigiusz Modrzejewski wrote: 1) work freely on my big change, committing atomic changes fl commit --private fl commit --private [...] fl commit --private 2) prepare to make a real commit fl up trunk fl merge private 3) make sure everything works as expected, commit to the world fl commit This feels intuitive and does not leave space for disaster. Furthermore, at step 3 you can see an aggregated diff of the final shape of your big change. And yes, I think of it as a patch queue. How would a stash add value? Apart from the fact, that you have to clone to a new repo to get rid of old private commits. Big change doesn't necessarily mean can be cut into smaller pieces. Especially in that case the incremental committing doesn't really work. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. This last sentence is the part I don't get. How is stash any more useful here that committing to a branch (public or private) or fork and then merging in a separate step? To my mind, it is just yet-another-command to have to learn. An alternative idea would be think about it in terms of a patch queue. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 12:55:27PM -0500, Richard Hipp wrote: On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. This last sentence is the part I don't get. How is stash any more useful here that committing to a branch (public or private) or fork and then merging in a separate step? To my mind, it is just yet-another-command to have to learn. Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: On Wed, Dec 15, 2010 at 12:55:27PM -0500, Richard Hipp wrote: On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. This last sentence is the part I don't get. How is stash any more useful here that committing to a branch (public or private) or fork and then merging in a separate step? To my mind, it is just yet-another-command to have to learn. Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. I prefer the current fossil undo option (with later commit to a branch), and I don't like much those automatic merges done directly, unless they are optional. The fossil undo + new branch, for those who believe in saving as much as possible in the history of the file tree, even encourages the public resolution of the merge. For those not wanting to save that publicly, those can even use -private. I don't think we need 'stash'; at most, I think we would get advantage of: - a precise description of what fossil undo is going to do in any case. Maybe it is only my trouble, but I'm not sure what will happen if I run undo after I changed things after fossil merge, for example. - and a reliable way of detecting if the merge is trivial or not, to be able to to undo + branch as soon as possible in case of non triviality. The recent improvement on notifying conflicts goes in that direction, I think. Regards, Lluís. ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 10:50:52PM +0100, Lluís Batlle i Rossell wrote: On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. I prefer the current fossil undo option (with later commit to a branch), and I don't like much those automatic merges done directly, unless they are optional. The trouble with fossil undo is that it throws away the state at some point, e.g. it very volatile and I wouldn't trust it with my data. Automatic merge + commit should definitely be optional behavior. It might make sense to use it as default and fall back to manual merging otherwise. The fossil undo + new branch, for those who believe in saving as much as possible in the history of the file tree, even encourages the public resolution of the merge. For those not wanting to save that publicly, those can even use -private. I would prefer to know in advance whether I can merge without problems or not. Problems against the base revision, not the working copy. This is important to decide whether I have to get a new working copy to do the merge, especially when working on a private branch. I don't think we need 'stash'; at most, I think we would get advantage of: - a precise description of what fossil undo is going to do in any case. Maybe it is only my trouble, but I'm not sure what will happen if I run undo after I changed things after fossil merge, for example. Ack. - and a reliable way of detecting if the merge is trivial or not, to be able to to undo + branch as soon as possible in case of non triviality. The recent improvement on notifying conflicts goes in that direction, I think. Ack. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Stash. Was: How should Fossil handle this merge conflict...
On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.comwrote: It would be nice to have something like `git stash`, too. Probably the biggest thing I miss from git. I've been reading up on git-stash to see if Fossil needs a similar feature. So far I don't see the need, since stash doesn't do anything that Fossil doesn't already handle more or less automatically. Please enlighten me if I'm missing something obvious Several cases where the git-stash manpage and other resources recommend using git-stash are shown below, together with how you would do the same thing in Fossil (without a stash). Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a private unpushable branch to store your incomplete change. I don't see how git-stash is any easier than fossil commit -private. In fact, it seems that commit -private is a little easier since it does not require learning a new mechanism (stash versus commit) but rather just a variation on an existing mechanism (commit) which presumably you already know very well. Scenario (3): You start out making changes but later decide that you want to put those changes on a branch, so you git-stash, then git-branch-new to create the new branch, then git-stash-pop, then git-commit. In Fossil, all that extra work is not necessary. You can commit to a branch at any time simply by adding the --branch argument to the fossil commit command line. And, you can even move a check-in that is already committed into a new or different branch using the check-in-edit feature of the fossil ui command. Fossil treats all check-ins as belonging to a single global DAG. Branches are designated using tags, which can be changed and rearranged after-the-fact. Git, on the other hand, appears to keep a separate DAG for each branch, meaning that checkins cannot be so easily move from one branch to another, necessitating tricks like the use of stash. So in summary - Fossil appears to already do everything that git-stash does and do it at least as easily as git-stash. Furthermore, I think for the sake of usability that is important to keep Fossil as simple as possible and avoid adding unneeded features. And for those reasons, I'm thinking it would not be a good idea to add a stash to Fossil. But I am open to arguments to the contrary. What say you? -- 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] Stash. Was: How should Fossil handle this merge conflict...
On Tue, 14 Dec 2010 20:09:58 -05 wrote: Richard So in summary - Fossil appears to already do everything that Richard git-stash does and do it at least as easily as git-stash. Richard Furthermore, I think for the sake of usability that is Richard important to keep Fossil as simple as possible and avoid Richard adding unneeded features. And for those reasons, I'm thinking Richard it would not be a good idea to add a stash to Fossil. But I Richard am open to arguments to the contrary. Richard Richard What say you? I agree...That's because Fossil is, in comparison with Git, properly designed while Git is more or less bunch of hacks thrown together with horrible UI on top of that...and now it's not easy to fix it. :-) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Stash. Was: How should Fossil handle this merge conflict...
On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.comwrote: It would be nice to have something like `git stash`, too. Probably the biggest thing I miss from git. I've been reading up on git-stash to see if Fossil needs a similar feature. So far I don't see the need, since stash doesn't do anything that Fossil doesn't already handle more or less automatically. Please enlighten me if I'm missing something obvious I agree, I never saw what would be 'stash' useful for, in fossil. When I used git, I used stash though. As in fossil, git users can branch at any point, commit on private branches and all that. But I think that there 'stash' got in because the git manuals somehow end up advising against branching too much. Additionally, I think that git programmers tend up to choose it as it allows more unorganized ways of storing private things. And related to 'stash', I enjoy fossil not having the INDEX and the Working Directory. Thank you, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
