Re: [fossil-users] git vs fossil again (was: why you should not shun)
+1. Shunning a commit is a bad idea. But fossil will not differentiate type of content when shunning so not sure if it can prevent shunning a commit. - Original Message - From: Erlis Vidal Sent: 10/06/11 12:21 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] git vs fossil again (was: why you should not shun) I get the two points of view and I'm not saying one is right or wrong. Modifying the history versus keeping everything as indeed happens (the history after all) Yesterday I was confused because I though the shun was done in the big file, but indeed the shun was done in the commit also... will that modify the history? I got the feeling that shunning a commit will change the history... not sure about it, you tell me. If I'm working under the premisses that the history cannot be changed, is shunning a commit (in case it change the history) a valid operation? Maybe fossil shouldn't allow to shun a commit, just individual files, if you really want to shun all files in that commit, then fossil could allow that, (shun --all) but that shouldn't touch ever the commit artifact.. Regards, Erlis On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 5 Oct 2011 11:12:31 -0700 Mike Meyer m...@mired.org wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Correct. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. I'm not entirely convinced. Look at the workflow used by the Git team: they maintain the set of well known branches, of which the only one, named pu (proposed updates), is allowed to be rebased and that's actually what happens with it each time the new release is made--it's cut from the master afresh. I mean, while every committer has `git rebase` at their disposal and knows how it works this does not mean they go off and break the repository with rebases. So your point is only really valid when the project is run by a bunch of idiots or complete newbies. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Git handles it from the opposite direction by having the reflog. But I find this point to be valid, yes, safety nets are a must when it comes to handling precious data. BTW I'm a fan of `fossil undo` for that matter. Bottom line: while more features may imply more powerful, it doesn't imply better. Moot point. I really miss Git's index and `git add --patch` here. Is Fossil better than Git in this respect by not having those more features? Surely it completely is in the eye of the beholder. ___ 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] git vs fossil again (was: why you should not shun)
On Wed, Oct 05, 2011 at 06:06:07PM +0200, Michal Suchanek wrote: 2011/10/5 Lluís Batlle i Rossell virik...@gmail.com: git looks to me as a tool for publishing development steps, not necessarily very related to the development history. The 'git version graph' is determined by the users the same way as they choose filenames or directories, and many git groups even consider keeping the git graph close to development history as a 'basic and inexpert approach' to git. It is because it is not useful to have every *actual file edit* recorded as commit. You often edit multiple files to perform a change, or do some work on the project, save it, go for lunch, and then do some more work on it. From a totally purist point of view should the history be recorded every time you save a file? Every time you write or delete a character? No, it is saved in logical pieces - commits. I consider commits as relevant milestones in the development, and I use branches to keep differentg granularity of commits. And when you find an issue with a commit that is some way back in your personal branch it is more logical and easier to review your branch if you append the fix to the commit where it belongs logically or if you append it at the top of the history interspersed with some possibly unrelated changes? Exactly, these are usual arguments among git lovers. Nevertheless, git manuals say every commit represents a state of the tree. Then you may find logical to expect that every commit log talks about a state of the tree. BUT all this goes away, when you start using 'rebase'. The commit logs once written do not match anymore the 'state of the tree' at the time of commit log writing. Assertions in commit logs like this part works may easily not fit what was meant at the commit time, for example. git even comes with 'quick automatic rebase' facilities, that allow not rechecking any commit log (a task hard to do, in any case). Making a review 'easier' by manipulating history can also end up being some kind of manipulation to a reviewer. A reviewer may judge better by understanding the development. I don't mind fossil keeping these dead branches. In fact, git does so too until you manually prune the repository of unreferenced objects. You can also select to show only live branches in fossil so the difference is mostly cosmetical, as are all the differences between distributed VCSes. git even cannot store branch histories, beyond the big resulting graph of unnamed commits. For example, a branch name can only designate a commit (leaf), not more than one. And branch names are not part of history. Some git deployments even forbid or limit pushing new branches to a public repository. On the other hand, fossil will always respect the checkin order, and the states related to every checkin log. As many other VCS, but not with git. 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] git vs fossil again (was: why you should not shun)
On Wed, 5 Oct 2011 18:24:30 +0200 Lluís Batlle i Rossell virik...@gmail.com wrote: [...] And when you find an issue with a commit that is some way back in your personal branch it is more logical and easier to review your branch if you append the fix to the commit where it belongs logically or if you append it at the top of the history interspersed with some possibly unrelated changes? Exactly, these are usual arguments among git lovers. Nevertheless, git manuals say every commit represents a state of the tree. Then you may find logical to expect that every commit log talks about a state of the tree. BUT all this goes away, when you start using 'rebase'. The commit logs once written do not match anymore the 'state of the tree' at the time of commit log writing. Assertions in commit logs like this part works may easily not fit what was meant at the commit time, for example. git even comes with 'quick automatic rebase' facilities, that allow not rechecking any commit log (a task hard to do, in any case). Making a review 'easier' by manipulating history can also end up being some kind of manipulation to a reviewer. A reviewer may judge better by understanding the development. That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. ___ 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] git vs fossil again (was: why you should not shun)
On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Bottom line: while more features may imply more powerful, it doesn't imply better. mike ___ 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] git vs fossil again (was: why you should not shun)
On 5 October 2011 20:12, Mike Meyer m...@mired.org wrote: On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. No, that's not how things work. Rebase is nothing more than taking commits comprising a branch from its branching point and applying them somewhere else. Not that complicated, really. As applying patches is doable, even patches stored in fossil history already, this is doable with a bit of scripting around fossil as it is doable with git. So not having the feature is not perfect defence, it only defends against people who don't care about the feature. People who find it useful for their workflow and want to use fossil for compatibility with upstream of for other features it provides can do so. As an alternative you could use export/rebase/import which is just different way to script this on a higher level. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. You can shoot yourself in the foot with any tool. Using tools that suit your workflow makes that less likely, being dangerous or not. I personally make a copy of any branch before rebasing it because in the case rebasing fails you can still revert it but comparing with the old branch makes it much clearer where you ended up. If you never delete anything it makes your work safer but your repository more hairy. Thanks Michal ___ 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] git vs fossil again (was: why you should not shun)
On Wed, 5 Oct 2011 11:12:31 -0700 Mike Meyer m...@mired.org wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Correct. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. I'm not entirely convinced. Look at the workflow used by the Git team: they maintain the set of well known branches, of which the only one, named pu (proposed updates), is allowed to be rebased and that's actually what happens with it each time the new release is made--it's cut from the master afresh. I mean, while every committer has `git rebase` at their disposal and knows how it works this does not mean they go off and break the repository with rebases. So your point is only really valid when the project is run by a bunch of idiots or complete newbies. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Git handles it from the opposite direction by having the reflog. But I find this point to be valid, yes, safety nets are a must when it comes to handling precious data. BTW I'm a fan of `fossil undo` for that matter. Bottom line: while more features may imply more powerful, it doesn't imply better. Moot point. I really miss Git's index and `git add --patch` here. Is Fossil better than Git in this respect by not having those more features? Surely it completely is in the eye of the beholder. ___ 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] git vs fossil again (was: why you should not shun)
On Wed, Oct 5, 2011 at 11:38 AM, Michal Suchanek hramr...@centrum.czwrote: On 5 October 2011 20:12, Mike Meyer m...@mired.org wrote: On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. No, that's not how things work. Rebase is nothing more than taking commits comprising a branch from its branching point and applying them somewhere else. Not that complicated, really. No, that's not how things work. Either that, or the git rebase documentation is really badly broken. It sure looks to me like rebase moves the patches from one point to another in the repo. As applying patches is doable, even patches stored in fossil history already, this is doable with a bit of scripting around fossil as it is doable with git. So not having the feature is not perfect defence, it only defends against people who don't care about the feature. People who find it useful for their workflow and want to use fossil for compatibility with upstream of for other features it provides can do so. If rebase moves the patches, then the two operations are different. This is basically a merge - except you're doing it outside the SCM, so you get two copies of the patches. But whether you do it inside or outside the SCM, you wind up with a history of the patches having been applied twice. Rebase changes that. mike ___ 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] git vs fossil again (was: why you should not shun)
I get the two points of view and I'm not saying one is right or wrong. Modifying the history versus keeping everything as indeed happens (the history after all) Yesterday I was confused because I though the shun was done in the big file, but indeed the shun was done in the commit also... will that modify the history? I got the feeling that shunning a commit will change the history... not sure about it, you tell me. If I'm working under the premisses that the history cannot be changed, is shunning a commit (in case it change the history) a valid operation? Maybe fossil shouldn't allow to shun a commit, just individual files, if you really want to shun all files in that commit, then fossil could allow that, (shun --all) but that shouldn't touch ever the commit artifact.. Regards, Erlis On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 5 Oct 2011 11:12:31 -0700 Mike Meyer m...@mired.org wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Correct. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. I'm not entirely convinced. Look at the workflow used by the Git team: they maintain the set of well known branches, of which the only one, named pu (proposed updates), is allowed to be rebased and that's actually what happens with it each time the new release is made--it's cut from the master afresh. I mean, while every committer has `git rebase` at their disposal and knows how it works this does not mean they go off and break the repository with rebases. So your point is only really valid when the project is run by a bunch of idiots or complete newbies. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Git handles it from the opposite direction by having the reflog. But I find this point to be valid, yes, safety nets are a must when it comes to handling precious data. BTW I'm a fan of `fossil undo` for that matter. Bottom line: while more features may imply more powerful, it doesn't imply better. Moot point. I really miss Git's index and `git add --patch` here. Is Fossil better than Git in this respect by not having those more features? Surely it completely is in the eye of the beholder. ___ 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
