Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams wrote: Actually I agree with most of Mike Meyer's reply, but I wanted to pick this paragraph apart: > How many times have you submitted a patch to an upstream Well, phrasing it like that says that you are thinking git-style anyway. Let's assume a Fossil push with one commit nominated as "this is my current contribution". > and then been told to make a bunch of changes, That's only to be expected, so you create a new commit based on your previous nominated one, push it and tell them which is your new commit. > re-organize your commits, I don't see why they (the centre) should do that. It's the result that matters, and if they want a pristine tree that includes only approved commits they can do that. (See below.) > make specific changes to specific commits, Why, why, why? It's the result that matters, this is just rewriting _your_ history because they feel like it. > and/or squash commits? Again, this is about them wanting a pristine tree. Their problem. > Yeah, that's why rebase is good. Rebase is a lie! Rebase is a lie! Rebase is a lie! Now for the "pristine tree" thing. I don't agree with it but if that's what the project leads want, they can 1) not permit pushes or syncs, only pulls, and take only real patches, which they turn into commits themselves or 2) have two repositories, a working rep which everybody syncs with, and a clean one. Then have a command/script like accept which creates a new child commit in the clean rep and does a pull back into the working rep, and which is simple in concept, though there will be issues about moves and deletes. Working this way also raises issues about what to do with wiki pages, tickets, and events. These approaches are not the outright lie that rebase tends to be, but merely the leads saying "here is the history of the things we have approved". They are then depriving everyone of the history of blind alleys (which will therefore be followed again and again) and of the ideas whose time had not yet come (which will therefore have to be re-invented from scratch, or may even be forgotten altogether!). I think the correct way to deal with "unwanted" commits is to make proper use of branches, and perhaps to have a UI option which shows only things in a specified set of branches. Incidentally, there is nothing stopping you, as a remote, barely-trusted developer (which is what you are in that sort of scenario) from running the two-repository process yourself, so that you sync only from your "clean" repository. I also think that much of the "mess" in repositories that people seem to want to hide is the result of committing far too frequently, usually in the mistaken belief that their VCS is some sort of backup system. Eric -- ms fnd in a lbry ___ 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] Fossil vs. Git/Mercurial/etc.?
(top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities. I can't tell what was first: the shame, shameful vcs usage, or the access to rebase feature. I dislike how git handles rebase, because by default it does not invite to rewriting commit logs. If you read git manuals, you are told that each commit (and its log) refers to a unique *file tree* (represented by the hash), and not to a *diff*. But then, they wrote 'rebase', which keeps the commit logs, but changes all the file trees they were meant for. Then you have commit logs that say "I tested this, and this works". If you rebase that commit, that looses all that meaning. In fossil, a hash refers to a specific file tree, that never changes, and checkin comments refer to that hash. History rewriting also implies that what you could have in your brain memory on how you developed something could not match what you have left in the VCS - after mangling with rebase. I find this also another source of problems. Regards, Lluís. On Sat, Dec 29, 2012 at 02:53:23PM +, Eric wrote: > On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams > wrote: > > > Actually I agree with most of Mike Meyer's reply, but I wanted to pick > this paragraph apart: > > > How many times have you submitted a patch to an upstream > > Well, phrasing it like that says that you are thinking git-style anyway. > Let's assume a Fossil push with one commit nominated as "this is my > current contribution". > > > and then been told to make a bunch of changes, > > That's only to be expected, so you create a new commit based on your > previous nominated one, push it and tell them which is your new commit. > > > re-organize your commits, > > I don't see why they (the centre) should do that. It's the result that > matters, and if they want a pristine tree that includes only approved > commits they can do that. (See below.) > > > make specific changes to specific commits, > > Why, why, why? It's the result that matters, this is just rewriting > _your_ history because they feel like it. > > > and/or squash commits? > > Again, this is about them wanting a pristine tree. Their problem. > > > Yeah, that's why rebase is good. > > Rebase is a lie! > Rebase is a lie! > Rebase is a lie! > > > Now for the "pristine tree" thing. I don't agree with it but if that's > what the project leads want, they can > > 1) not permit pushes or syncs, only pulls, and take only real patches, > which they turn into commits themselves > > or > > 2) have two repositories, a working rep which everybody syncs with, and > a clean one. Then have a command/script like > > accept > > which creates a new child commit in the clean rep and does a pull back > into the working rep, and which is simple in concept, though there > will be issues about moves and deletes. > > Working this way also raises issues about what to do with wiki pages, > tickets, and events. > > These approaches are not the outright lie that rebase tends to be, > but merely the leads saying "here is the history of the things we have > approved". They are then depriving everyone of the history of blind > alleys (which will therefore be followed again and again) and of the > ideas whose time had not yet come (which will therefore have to be > re-invented from scratch, or may even be forgotten altogether!). > > I think the correct way to deal with "unwanted" commits is to make proper > use of branches, and perhaps to have a UI option which shows only things > in a specified set of branches. > > > Incidentally, there is nothing stopping you, as a remote, barely-trusted > developer (which is what you are in that sort of scenario) from running > the two-repository process yourself, so that you sync only from your > "clean" repository. > > I also think that much of the "mess" in repositories that people seem to > want to hide is the result of committing far too frequently, usually in > the mistaken belief that their VCS is some sort of backup system. > > Eric > -- > ms fnd in a lbry > ___ > 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] Fossil vs. Git/Mercurial/etc.?
On Sat, 29 Dec 2012 16:20:32 +0100 Lluís Batlle i Rossell wrote: Top post due to... okay. The last three messages to this thread look somewhat alarming. In the first message of these, Mike Meyer, first ruled out the whole tool (Git) due to hating its optional feature and then proceeded with a fancastic technical argument against it: "None. Zero. Nada. Never.". The second one, from Eric, contained the exclamation "Rebase is a lie!" repeated three times in a row. And now I'm reading about Git users ashamed for the histories they create. You guys do really sound as a religious sect. Of course, this is a pro-Fossil list, but I fail to understand why such bashing of a rival DVCS and preaching are really required: those who might be "converted" are unlikely to read this list anyway (they're supposedly busy reading "Pro Git" now), and those who are reading this list admittedly prefer dry technical arguments. Actually, I intended to write a calm and purely technical response to Mike's message pointing out the ideas Git devs had while implementing rebasing (I failed to see in this thread any notice of using rebasing to help future bisecting, for instance), but the next two messages urged me to write this rather off-topic semi-rant. TL;DR I would really like to have such discussions be more technical and less zealous, if possible, please. > (top post, due to the complexity of the previous post) [...] ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 07:55:28PM +0400, Konstantin Khomoutov wrote: > On Sat, 29 Dec 2012 16:20:32 +0100 > Lluís Batlle i Rossell wrote: > You guys do really sound as a religious sect. :) well, I think that everyone expects different jobs to be done by a VCS. As for me, I like it to keep history as it happened. Then, fine if it has methods to reorganize the data in there, but without loosing the original history. Some people see the VCS as a tree where they organize the past development in the way they prefer, not necessarily linked to history. > Actually, I intended to write a calm and purely technical response to > Mike's message pointing out the ideas Git devs had while implementing > rebasing (I failed to see in this thread any notice of using rebasing to > help future bisecting, for instance), but the next two messages urged > me to write this rather off-topic semi-rant. Git people that rewrite history (using rebase), will tell that they reorganize the commits so they become "more logical". Git does not have a way of doing that without loosing the history of how all happened. Of course, git can be used without rebasing. I just haven't met anyone (even me, who contributes using git in different projects) who doesn't use rebase. And I use it, because the rest of the team don't want the git graphs "crippled with _unnecessary_ merges". > TL;DR Well, there you go. For some people, writing is easier than reading. ;) > I would really like to have such discussions be more technical and less > zealous, if possible, please. Well, I think all this ends up being a matter of taste. Everyone shows their views. It's like choosing an OS... Some people chose GNU/Linux, despite all the effort that it requires, because they prefer dealing with fdisk, filesystems, kernel updates, package managers, ... than to have the problems of Microsoft Windows (OS corruption, silent updates, hidden coed, dll hell, crashes, viruses, etc.). But some people prefer the problems of Windows. It's a matter of choosing the problems that annoy you less. :) And as I mentioned, some people see advantages in having those 'remote' trees locally, and there are situations where they can be convenient. But for most of the development I do in a VCS, that's far too heavy. 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov wrote: > In the first message of these, Mike Meyer, first ruled out the whole > tool (Git) due to hating its optional feature If you're going quote someone out of context, at least get their reasons right. You called rebase a "killer feature" of git. Ok, you like it. I consider rebase a serious misfeature, as it reflects an underlying philosophy for the tool that I flat disagree with. As far as I can tell, rebase is *not* optional. At least, it's enabled in my install of git, and I've never run into a way to disable it (or, for that matter, a git tutorial that didn't gush about how cool and wonderful the rebase command was). This should be compared to mercurial, where rebase is available - but in an extension that's turned off by default. *That's* an optional feature. You may enjoy trying to force your philosophy onto a tool that was designed with a completely different philosophy in mind, but I've got better things to do. There are DSCMs designed with a philosophy that I agree with. I'll use those, and not annoy the git folks by trying to get them to remove history-altering commands. > and then proceeded with a > fancastic technical argument against it: "None. Zero. Nada. Never.". That wasn't a technical argument, that was an answer to a question you asked. Ok, maybe your question was rhetorical because you assumed everyone would have the same answer you do, but my answer is still "None. I have never been asked to edit commits on a submitted patch." In any way. I don't think I've ever worked on a project were asking someone to edit commits would be considered acceptable behavior. You totally ignored my question to you, which asked for more details about your proposal. While rebase pretty much isn't going to happen (as I explained, it's contrary to the philosophy of fossil), you suggested a feature that sounded like it wouldn't clash with that philosophy. However, your description was rather vague. If you can get off your high horse long enough to describe what you'd like done in terms of commits and how they show up on the new branch, as opposed to "rebase", it might get some consideration. But please don't continue wasting everyone's time by just complaining that people disagree with you. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell wrote: > (top post, due to the complexity of the previous post) > > I've found many git-fans that are completely ashamed of how they develop. > And > they would never make public how they commit things (how they use the > VCS), so > they don't accept other VCS that hasn't git rebasing capabilities. > > I can't tell what was first: the shame, shameful vcs usage, or the access > to > rebase feature. > I'm one of those "losers" who uses fossil as a sort of backup work area sync tool in addition to a pure SCM. Now I don't personally feel the label loser applies to me but I'm using it here because repeatedly now on this list, intentional or accidentally, folks are using words that leave the impression that people who use fossil this way are, well, losers. Judging others in this way is not constructive IHMO. Perhaps instead try to understand why people are compelled to do this "wrong" behavior and perhaps enhance the tool(s) to make it unnecessary. Rebase exists because it meets a real need. The question is, can that need be met in a more elegant way with fossil? I work on several projects that are spread out over different machines and are not always accessible to me from all locations where I work. I often (yes, often) have work in progress that is far from polished yet if I don't check it in I have no easy way to continue working later from a different location. The pragmatic solution for me is to check in the current state of the code regardless of whether it is polished or not. I even (horrors) occasionally check in stuff that won't compile. I could use private branches to keep this clean but that adds another thing to remember and manage to my already overfilled plate and I've found it very easy to accidentally lose work with private branches. What I would like is a way to mark branches as hidden. A hidden branch does not show up on the timeline. In the UI there would be a "show hidden branches" button but by default they would not show. I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. Just my $0.02. Cheers and seasons greetings to all fossilers :) > > I dislike how git handles rebase, because by default it does not invite to > rewriting commit logs. If you read git manuals, you are told that each > commit > (and its log) refers to a unique *file tree* (represented by the hash), > and not > to a *diff*. But then, they wrote 'rebase', which keeps the commit logs, > but > changes all the file trees they were meant for. > > Then you have commit logs that say "I tested this, and this works". If you > rebase that commit, that looses all that meaning. In fossil, a hash refers > to a > specific file tree, that never changes, and checkin comments refer to that > hash. > > History rewriting also implies that what you could have in your brain > memory on how you developed something could not match what you have left in > the VCS - > after mangling with rebase. I find this also another source of problems. > > Regards, > Lluís. > > On Sat, Dec 29, 2012 at 02:53:23PM +, Eric wrote: > > On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams > wrote: > > > > > > Actually I agree with most of Mike Meyer's reply, but I wanted to pick > > this paragraph apart: > > > > > How many times have you submitted a patch to an upstream > > > > Well, phrasing it like that says that you are thinking git-style anyway. > > Let's assume a Fossil push with one commit nominated as "this is my > > current contribution". > > > > > and then been told to make a bunch of changes, > > > > That's only to be expected, so you create a new commit based on your > > previous nominated one, push it and tell them which is your new commit. > > > > > re-organize your commits, > > > > I don't see why they (the centre) should do that. It's the result that > > matters, and if they want a pristine tree that includes only approved > > commits they can do that. (See below.) > > > > > make specific changes to specific commits, > > > > Why, why, why? It's the result that matters, this is just rewriting > > _your_ history because they feel like it. > > > > > and/or squash commits? > > > > Again, this is about them wanting a pristine tree. Their problem. > > > > > Yeah, that's why rebase is good. > > > > Rebase is a lie! > > Rebase is a lie! > > Rebase is a lie! > > > > > > Now for the "pristine tree" thing. I don't agree with it but if that's > > what the project leads want, they can > > > > 1) not permit pushes or syncs, only pulls, and take only real patches, > > which they turn into commits themselves > > > > or > > > > 2) have two repositories, a working rep which everybody syncs with, and > > a clean one. Then have a command/script like > > > >
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sat, 29 Dec 2012 10:24:05 -0600 Mike Meyer wrote: > > In the first message of these, Mike Meyer, first ruled out the whole > > tool (Git) due to hating its optional feature > > If you're going quote someone out of context, at least get their > reasons right. > > You called rebase a "killer feature" of git. No, that wasn't me. > Ok, you like it. I > consider rebase a serious misfeature, as it reflects an underlying > philosophy for the tool that I flat disagree with. As far as I can > tell, rebase is *not* optional. At least, it's enabled in my install > of git, and I've never run into a way to disable it (or, for that > matter, a git tutorial that didn't gush about how cool and wonderful > the rebase command was). This should be compared to mercurial, where > rebase is available - but in an extension that's turned off by > default. *That's* an optional feature. No, an optional feature is the one you are not forced to use. I have a bunch of Git users in the company I work at who never touched `git rebase` though they supposedly read about it. They just don't need this feature and so they don't use it. If you call rebasing a non-optional feature, go ahead and claim all users of Git must commit to Subversion because Git includes the `git svn` tool and must send patches by e-mail as it also has `git format-patch`. If Git had rebasing instead of merging, you could make your point, but with the current state of affairs you can't. > You may enjoy trying to force your philosophy onto a tool Not me, again. [...] > But please don't continue wasting everyone's time by just complaining > that people disagree with you. I suggest you to calm down. I see my plead to not being zealous was in vain, so just please calm down at least. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov wrote: > I suggest you to calm down. I see my plead to not being zealous was in > vain, so just please calm down at least. I am calm. Yes, I'm a little bit bothered about being insulted in various ways, but I'm trying to return the discussion to the technical merits of a proposal by getting a more detailed proposal from the OP. If you can't contribute to that technical discussion, please don't contribute to the discussion. http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sat, 29 Dec 2012 19:55:28 +0400, Konstantin Khomoutov wrote: > On Sat, 29 Dec 2012 16:20:32 +0100 > LluÃs Batlle i Rossell wrote: > >> Top post due to... > okay. > The last three messages to this thread look somewhat alarming. > > In the first message of these, Mike Meyer, first ruled out the whole > tool (Git) due to hating its optional feature and then proceeded with a > fancastic technical argument against it: "None. Zero. Nada. Never.". Software choice often comes down to a single feature, and "optional" in this case means that the project lead can't stop others doing it, except by policy, which doesn't work. And what's wrong with emphasizing the fact that the suggested motivations for rebase have never happened to him? > The second one, from Eric, contained the exclamation "Rebase is a lie!" > repeated three times in a row. Would you have been happier if I'd only said it once without the exclamation mark? It's been said here before by others as well, and it's how we see it. > And now I'm reading about Git users ashamed for the histories they > create. I must admit I don't get that one at all. > You guys do really sound as a religious sect. We have our opinions, we are convinced of them, and we are still waiting for a counter-argument that even approaches convincing. > Of course, this is a pro-Fossil list, but I fail to understand why such > bashing of a rival DVCS and preaching are really required: Bashing and preaching? Such emotive words, and I don't think anyone is doing them. I personally am merely somewhat annoyed by those who want Fossil to have something just because Git (or some other program) has it. I want to know what problem rebase (or whatever feature someone wants) solves, then we can figure out if that problem even exists in the same form in Fossil, and then how to fix the problem in Fossil in a way compatible with the philosophy of Fossil. > those who might be "converted" are unlikely to read this list anyway > (they're supposedly busy reading "Pro Git" now), and those who are > reading this list admittedly prefer dry technical arguments. No conversion attempts, but we need methodology arguments as well as technical ones to avoid finding beautiful technical solutions to the wrong problems. > Actually, I intended to write a calm and purely technical response to > Mike's message pointing out the ideas Git devs had while implementing > rebasing (I failed to see in this thread any notice of using rebasing to > help future bisecting, for instance), but the next two messages urged > me to write this rather off-topic semi-rant. Please write that response anyway, especially if you know what the Git devs had in mind. Maybe there's something we don't know. Maybe we'll disagree, but at least we'll be arguing about the right things. > TL;DR > I would really like to have such discussions be more technical and less > zealous, if possible, please. Software development is a human activity, so ... Eric -- ms fnd in a lbry ___ 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] Fossil vs. Git/Mercurial/etc.?
tl;dr: we agree that public history should not get rewritten. You missed the point of when, where, and why I need rebase. On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote: > Nico Williams wrote: >>Rebase is one of teh killer features of git. > > It certainly kills any interest I have in using git on a regular basis. Why? You don't have to use it if you don't want to. >>How many times have you submitted a patch to an upstream and then been >>told to make a bunch of changes, re-organize your commits, make >>specific changes to specific commits, and/or squash commits? Yeah, >>that's why rebase is good. > > None. Zero. Nada. Never. > > The thing is, I actually submit a *patch*, not a pull request or a commit > history or anything that would invite such a request. That's also how I work > merges between branches: the mrege is a single commit that incorportes all > the changes from the other branch, or on rare occaisions a cherry-picked set > of changes. The history is still there in the old branch if I want to review > it, but the commit log for the trunk is nice and clean. It all depends on the upstream though, doesn't it. I've worked with projects where the upstream want commits split because arguably a given commit does two things instead of one (e.g., fix a bug and a buglet). And that's just one example. Other times I start out coding a large feature and worry about splitting things up into sensible chunks of patches later. Or I leave a typo in a commit and need to go fix it, but adding a commit just for that is not desired by the upstream. Whatever the case, I have to rebase quite often. For *my* projects that are not ready to take contributions I just don't bother rebasing, but if I were a maintainer for a large project I too would want clean patches, and that may mean that contributors have to rebase sometimes. > That's one of the philosophical differences that determine which of the DSCMs > you want to use. If the philosophy is that history is important, then you > never rebase, and nobody would dream of asking you to make changes to your > commits beyond making the comments more accurate. Rebase is not merely > unnecessary, but anathema. You missed the point. The only thing that should ever get rebased is private branches (i.e., that no one should ever pull from). Once something's in an official repo it should never get rebased. So you see, we don't really disagree. > If, on the other hand, the repository is considered to be part of the public > face of the project like user docs or the web site, then editing it for > readability and marketing purposes is SOP, and rebase is a critical tool. This is an interesting use case, one I had not considered. >>Fossil is designed to avoid destructive operations. Rebasing is a >>destructive operation. A compromise would be to allow rebasing but >>into a new branch, leaving the original alone -- this is how I do >>rebases in git anyways. > > I think you need to be mor explicit. Rebase is used for a number of different > things, most in my (admittadly limited) experience with rebase it involves > moving one branchinto another. It sounds like you're wanting to use it to > rewrite a single branches history onto a new branch. If that's the case, > can't you just do it with a series of cherry-picked merges? If so, could > provide an example and show how rebase would make it easier? If not, maybe > explain what you want to do? That's exactly what rebasing is. Here's the difference between git and fossil then: git has a nice tool for interactive rebasing (several, really, if you count git add -p as a tool for rebasing because it is so useful when splitting commits); fossil doesn't have that. Can I rebase with fossil? Yes, definitely. I just have to manually pick commits to merge, manually build the command lines, manually track the state of a complex rebase (this is the hardest part). And sure, I could script it, but the beauty of the git rebase -i interface should be built-in. 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 8:53 AM, Eric wrote: > On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams > wrote: > > > Actually I agree with most of Mike Meyer's reply, but I wanted to pick > this paragraph apart: > >> How many times have you submitted a patch to an upstream > > Well, phrasing it like that says that you are thinking git-style anyway. > Let's assume a Fossil push with one commit nominated as "this is my > current contribution". > >> and then been told to make a bunch of changes, > > That's only to be expected, so you create a new commit based on your > previous nominated one, push it and tell them which is your new commit. > >> re-organize your commits, > > I don't see why they (the centre) should do that. It's the result that > matters, and if they want a pristine tree that includes only approved > commits they can do that. (See below.) It matters a great deal. Let's say you submit a patch for the main branch and the maintainers of an older release branch want to pull your patch in for a micro release of that older release. If your patches are broken up into suitable pieces then the maintainers might pull some of your commits (e.g., bug fixes) but not others (e.g., riskier ones, features). But if your commits were badly organized then the maintainers will have to copy/paste or apply chunks of patches -- very manual, risky processes. To me what you say indicates that you have very little experience with *large* projects. I've worked on quite a few large projects. I'd drop names, but to what end. The key is this *happens*. A lot. And it's not just because the VCS supports rebase: I've had to do rebasing with VCSes that don't have explicit support for it, because if that's what the upstream wants, then that's what the upstream gets (or nothing at all, but what if your job -that you're paid for- is to contribute to that upstream?). >> make specific changes to specific commits, > > Why, why, why? It's the result that matters, this is just rewriting > _your_ history because they feel like it. Because that history is of a PRIVATE branch. PRIVATE. And the way I do it (go look at my github repos) is that I rebase brand new *copies* of the branch in question, so I never actually rewrite any history. (I thought I'd explained this. Hadn't I?) >> and/or squash commits? > > Again, this is about them wanting a pristine tree. Their problem. Or my problem: I want my fixes in. Or maybe I get paid to contribute to them. 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
wrote:
> (top post, due to the complexity of the previous post)
>
> I've found many git-fans that are completely ashamed of how they develop. And
> they would never make public how they commit things (how they use the VCS), so
> they don't accept other VCS that hasn't git rebasing capabilities.
If yoiu manage a *large* project, something on the order of OS/Net
(the core of Solaris), say, then you need a clean tree for various
reasons:
- so maintenance of older releases is easier
The maintainers of older releases can pull and merge specific
fixes for specific bugs from the next-release branch.
Without clean trees this is a disaster: you've lost organization of
history, thus finding specific fixes -complete sets of commits for them-
is often then as hard as just re-doing the work of fixing the bug in
the first place.
- to make it easier for *other* developers to find what happened
later, when you're no longer around to ask questions of, or when
you've forgotten the details.
- to make it easier for reviewers to understand just what the heck
your patches are about ("this one fixes this one bug", "that one
adds this minor feature", ...)
And so on. Really. Large projects need order, they need process.
They need clean trees in official repos.
Project repos? Let them have whatever ugly, dirty history. Official
repos? No way.
Without a way to clean history prior to pushing to / pulling into
official repos a VCS is just hard to use effectively.
That's my last word on this for a while. Take. Or leave it.
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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: > On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell > wrote: > > (top post, due to the complexity of the previous post) > > > > I've found many git-fans that are completely ashamed of how they develop. > > And > > they would never make public how they commit things (how they use the VCS), > > so > > they don't accept other VCS that hasn't git rebasing capabilities. > > And so on. Really. Large projects need order, they need process. > They need clean trees in official repos. > > Without a way to clean history prior to pushing to / pulling into > official repos a VCS is just hard to use effectively. I'm not against that; I understand that teams of projects want to organize what their "VCS history" looks like. What I meant is that (by now) git has only one way of providing such "clean trees": destroying the history. So, for that win (clean the trees at will), there is a forced work pattern: lose the history. For me the advantadges are less than the disadvantages. I think both can be achieved, in a VCS. For what I understand, Monotone has quite nice solutions to that. One thing is clean *visualisation* (or easy access, whatever), the other is modifying the raw historical data at the back. Git offers tools to manipulate the historical data, in order to achieve some visualisation. 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams wrote: >tl;dr: we agree that public history should not get rewritten. You >missed the point of when, where, and why I need rebase. Which is why I asked for clarification about that point. See below. >On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote: >> Nico Williams wrote: >>>Rebase is one of teh killer features of git. >> It certainly kills any interest I have in using git on a regular >basis. >Why? You don't have to use it if you don't want to. Because it indicates that the designers of git and I have a fundamental disagreement about what a SCM is for. This means it's very likely that using git is going to be one pita after another (which in fact it turns out to be). >It all depends on the upstream though, doesn't it. I've worked with >projects where the upstream want commits split because arguably a >given commit does two things instead of one (e.g., fix a bug and a >buglet). It doesn't all depend on the upstream. Part of it depends on you. You always have the option of saying "No" when someone makes such a request. >You missed the point. The only thing that should ever get rebased is >private branches (i.e., that no one should ever pull from). Once >something's in an official repo it should never get rebased. You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. >That's exactly what rebasing is. Here's the difference between git >and fossil then: git has a nice tool for interactive rebasing >(several, really, if you count git add -p as a tool for rebasing >because it is so useful when splitting commits); fossil doesn't have >that. Can I rebase with fossil? Yes, definitely. I just have to >manually pick commits to merge, manually build the command lines, >manually track the state of a complex rebase (this is the hardest >part). And sure, I could script it, but the beauty of the git rebase >-i interface should be built-in. This doesn't provide an answer to my question at all. A feature request can't simply be "I need other-scm's foo command". Especially when said command is one that is philosophically unsuited to fossil. For instance, I'd love to have hg's "rollback" command, but I'd never suggest it with those words. Instead, I described what it did, and suggested a command syntax, and possibilities for some problematic cases. I already got that you have a need for rebase that you think is compatible with fossil. You've provided a use case, and I agree that fossil could handle that reasonably. But you haven't actually proposed a new command for fossil, other than "rebase", which has already been rejected multiple times. Do you want a more controlled merge for this? I know I'd like a more controlled merge; compared to perforce's 3-step merge, everything else feels like throwing code at the wall and hoping the right bits stick. But maybe you want a less-controlled merge. I can't tell from the descriptions you've given. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell wrote: > On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: >> And so on. Really. Large projects need order, they need process. >> They need clean trees in official repos. >> >> Without a way to clean history prior to pushing to / pulling into >> official repos a VCS is just hard to use effectively. > > I'm not against that; I understand that teams of projects want to organize > what > their "VCS history" looks like. > > What I meant is that (by now) git has only one way of providing such "clean > trees": > destroying the history. That's a strawman. I very specifically suggested that a fossil rebase operation should *always* copy the branch being rebased and then rebase that copy. Now what on Earth could possibly be objectionable about that? 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote: > You missed the point. Nothing should *ever* be rebased. It's a rewrite of > history, which is a fundamentally bad thing. While a SCM should make > generating patch files easy, it shouldn't require rewrites of history to do > so. You missed my proposal that a fossil rebase operation always copy the branch being rebased and rebase that copy. It was in my very first post on this thread: | Fossil is designed to avoid destructive operations. Rebasing is a | destructive operation. A compromise would be to allow rebasing but | into a new branch, leaving the original alone -- this is how I do | rebases in git anyways. [...] I have to wonder how so many people missed it. My guess: those who missed it really can't get past the idea that git's rebase is destructive, therefore nothing even remotely like it can be considered, even if it explicitly prevents destruction. But that's not much of an excuse: that was a total of three short paragraphs you could have read before launching into a massive sub-thread. Perhaps we need a word for non-destructive (copying) rebase that -being a different word- fails to arouse such [misplaced] ire. 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 05:37:35PM -0600, Nico Williams wrote: > On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell > wrote: > > On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: > >> And so on. Really. Large projects need order, they need process. > >> They need clean trees in official repos. > >> > >> Without a way to clean history prior to pushing to / pulling into > >> official repos a VCS is just hard to use effectively. > > > > I'm not against that; I understand that teams of projects want to organize > > what > > their "VCS history" looks like. > > > > What I meant is that (by now) git has only one way of providing such "clean > > trees": > > destroying the history. > > That's a strawman. I very specifically suggested that a fossil rebase > operation should *always* copy the branch being rebased and then > rebase that copy. > > Now what on Earth could possibly be objectionable about that? Ah sorry, I was only talking about my objections against "git rebase". I don't know the best way to implement a feature that allows creating 'new history' at will (not destroying the old). All I can imagine sounds like a lot of work. :) 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell wrote: > Ah sorry, I was only talking about my objections against "git rebase". I don't > know the best way to implement a feature that allows creating 'new history' at > will (not destroying the old). > > All I can imagine sounds like a lot of work. :) The basic machinery (cherry-pick) is there. The main piece is the interactive rebase, which is really popping the user into $EDITOR to select the order of various operations, and which those are. So there's a) code to select commits, code to format that into a file the user will edit, spawn $EDITOR, then parse the result, then execute it. The execution part requires keeping state and is a bit tricky. The hardest part, I think would be anything like git add -p. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams wrote: >On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote: >> You missed the point. Nothing should *ever* be rebased. It's a >rewrite of history, which is a fundamentally bad thing. While a SCM >should make generating patch files easy, it shouldn't require rewrites >of history to do so. >You missed my proposal that a fossil rebase operation always copy the >branch being rebased and rebase that copy. It was in my very first >post on this thread: I didn't miss it. I asked for clarification, for two reasons: 1) Rebase involves two branches, both of which get changed. Your proposal only mentions one. Given that I'm not all that familiar with rebase, I have *no* idea what this means in terms of additions to the history tree. 2) Your use case (generating patches to make upstream happy) isn't one I've ever experienced, but it doesn't sound like it needs to change the tree at all. So, for the third time, can you describe your proposed new feature *without* saying the words "git" or "rebase". -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
I'm pretty sure that "rebase" or its equivalents will never be a part of Fossil. Given that there are tools out there (like Git) that feature this functionality that some (and I stress it's only *some*) users want, perhaps this following question is to practical but … why not use Git, the tool that has the feature you want? This arguing over whether rebase is good or bad and whether you're a good or bad person for wanting it is futile. I'm pretty damned sure that it's not going to ever be added (given Richard Hipp's philosophical stance on rewriting repository history). TL;DR version: stop whining and use Git if you want Git. On 30 December 2012 12:29, Mike Meyer wrote: > > > Nico Williams wrote: > > >On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote: > >> You missed the point. Nothing should *ever* be rebased. It's a > >rewrite of history, which is a fundamentally bad thing. While a SCM > >should make generating patch files easy, it shouldn't require rewrites > >of history to do so. > >You missed my proposal that a fossil rebase operation always copy the > >branch being rebased and rebase that copy. It was in my very first > >post on this thread: > > I didn't miss it. I asked for clarification, for two reasons: > > 1) Rebase involves two branches, both of which get changed. Your proposal > only mentions one. Given that I'm not all that familiar with rebase, I have > *no* idea what this means in terms of additions to the history tree. > > 2) Your use case (generating patches to make upstream happy) isn't one > I've ever experienced, but it doesn't sound like it needs to change the > tree at all. > > So, for the third time, can you describe your proposed new feature > *without* saying the words "git" or "rebase". > -- > Sent from my Android tablet with K-9 Mail. Please excuse my swyping. > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer wrote: > Nico Williams wrote: >>You missed my proposal that a fossil rebase operation always copy the >>branch being rebased and rebase that copy. It was in my very first >>post on this thread: > > I didn't miss it. I asked for clarification, for two reasons: > > 1) Rebase involves two branches, both of which get changed. Your proposal > only mentions one. Given that I'm not all that familiar with rebase, I have > *no* idea what this means in terms of additions to the history tree. In git, the rebase command rebases only the current branch. There's one or two other things to specify: and, optionally, , but these two need not be branch names. What I'm proposing is that in fossil the rebase operation create a new branch named after the currently checked out branch (or named by the user) with the rebased contents, leaving the original alone. The new branch should get checked out too (for obvious reasons, as the process of rebasing needs interim points checked out, and anyways, the user is likely to want the new branch checked out. > 2) Your use case (generating patches to make upstream happy) isn't one I've > ever experienced, but it doesn't sound like it needs to change the tree at > all. It produces a different set of commits to be sent upstream than I had before the rebase -- that's a "change to the tree", though, really, it's a new branch. In git the branch name is then changed to point to the new line of commits, and this change is what we all consider destructive. That you've not experienced this says nothing about the reality of it. For me the lack of rebase in any VCS is near fatal -- it's generally possible to obtain the same effect, even with fossil, but at the cost of much manual labor or much labor spent automating rebase tasks (never as well as git rebase does it anyways). > So, for the third time, can you describe your proposed new feature *without* > saying the words "git" or "rebase". No: it's too much work, and many people understand "git rebase", and it has documentation I can refer to. I don't want to copy that documentation nor find a way of expressing the same concepts differently -- that would be a waste of my time and would confuse all those users who know what git rebase is. I'd much rather instead offer a description as incremental change to "git rebase". Given these command-line synopses from the git-rebase manpage: git rebase [-i | --interactive] [options] [--onto ] [] git rebase [-i | --interactive] [options] --onto --root [] my proposal is for: fossil rebase [-i | --interactive] [options] [--new ] [--onto ] [] fossil rebase [-i | --interactive] [options] [--new ] --onto --root [] if is not given then would be derived from the selected (or current) by adding a suffix "-1" or by incrementing the number if ends in "-". 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 10:49 PM, Michael Richter wrote: > I'm pretty sure that "rebase" or its equivalents will never be a part of > Fossil. Given that there are tools out there (like Git) that feature this > functionality that some (and I stress it's only some) users want, perhaps > this following question is to practical but … why not use Git, the tool that > has the feature you want? This arguing over whether rebase is good or bad > and whether you're a good or bad person for wanting it is futile. I'm > pretty damned sure that it's not going to ever be added (given Richard > Hipp's philosophical stance on rewriting repository history). What is it about rebase that causes so many to miss the idea of a rebase that is NOT destructive because it creates a new branch instead of doing a destructive change to an existing branch? I shall wait for D. Richard Hipp's word as to any kind of rebase never making it into Fossil. > TL;DR version: stop whining and use Git if you want Git. You fail reading comprehension. I do use git, nearly exclusively. And I use rebase. And I use it in a way that is non-destructive (because I always rebase fresh branches that are copies of the ones I want to rebase). I happen to think that Fossil has a superior architecture and design. I'd like to use Fossil, but I can't, and I've explained why. I've also explained why I'm unlikely to be the only user who needs this one feature. 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams wrote: >What I'm proposing is that in fossil the rebase operation create a new >branch named after the currently checked out branch (or named by the >> So, for the third time, can you describe your proposed new feature >*without* saying the words "git" or "rebase". >No: it's too much work, and many people understand "git rebase", and -1. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote: >>> So, for the third time, can you describe your proposed new feature >>*without* saying the words "git" or "rebase". >>No: it's too much work, and many people understand "git rebase", and > > -1. So is that a -1 to the attitude, the proposal, or both? I can't tell. If the attitude, can you explain why you would want an explanation of "rebase" in words other than those that have already been used (probably by so many)? What's the problem with making reference to git? Is git anathema? Is this NIH syndrome? ___ 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] Fossil vs. Git/Mercurial/etc.?
On 30 December 2012 12:56, Nico Williams wrote: > What is it about rebase that causes so many to miss the idea of a > rebase that is NOT destructive because it creates a new branch instead > of doing a destructive change to an existing branch? > I don't know. You won't explain it. "It's too much work," remember? > I shall wait for D. Richard Hipp's word as to any kind of rebase never > making it into Fossil. > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html That alone would be a pretty strong indicator given the context of the thread it's in. Too, the fact that *two years after* the first round of requests for "rebase" there is still no rebase functionality and this conversation is coming up *yet again* is another pretty strong indicator. > > TL;DR version: stop whining and use Git if you want Git. > > You fail reading comprehension. > No, you just don't like my interpretation. > I do use git, nearly exclusively. And I use rebase. And I use it in > a way that is non-destructive (because I always rebase fresh branches > that are copies of the ones I want to rebase). > Good. So you're happy with Git. Keep using Git. You like its features and you don't like the fact Fossil doesn't have these features (and that it likely never will). There's no reason to make every DSCM turn into a Git clone. (Indeed there's every reason *not* to have a myriad of Git clones out and about!) > I happen to think that Fossil has a superior architecture and design. > Except part of its design is *no rewriting of history*. Hence, no "rebase" in the Git sense. > I'd like to use Fossil, but I can't, and I've explained why. So use Git. Nobody here is calling you a bad person because you're using Git. Nobody here is holding a gun to your head forcing you to use not-Git. > I've also explained why I'm unlikely to be the only user who needs this > one feature. > This is the C++ approach to things: add every conceivable feature because "someone, somewhere" might want to use it. The result is a language that should be an embarrassment with so much of a learning curve^H^H^H^H^H*cliff*that very few people (if any) could really be called "expert users". (The funniest part was that the standards committee decided to address this specific problem by *adding even more features*.) There's use cases for every bizarre feature in every bizarre SCM (distributed or otherwise) out there. Let's not turn Fossil into the C++ of DSCMs, shall we? If you *really, positively, absolutely* must have rebase, Git is that-a-way. Insisting that Fossil should turn into Git is not a viable argument. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Fossil vs. Git/Mercurial/etc.?
On 30 December 2012 13:02, Nico Williams wrote: > On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote: > >>> So, for the third time, can you describe your proposed new feature > >>*without* saying the words "git" or "rebase". > >>No: it's too much work, and many people understand "git rebase", and > > > > -1. > > So is that a -1 to the attitude, the proposal, or both? I can't tell. > If the attitude, can you explain why you would want an explanation of > "rebase" in words other than those that have already been used > (probably by so many)? What's the problem with making reference to > git? Is git anathema? Is this NIH syndrome? > I can't speak for Mike Meyer, but I'd -1 that attitude because you're basically saying, stripping away the pretty posturing, "I WANT THIS NEW FEATURE AND I WON'T EXPLAIN IT TO YOU BECAUSE THAT'S TOO MUCH WORK FOR ME INSTEAD I WANT YOU TO DO THE WORK FOR ME!" If you can't (or, rather, won't!) explain Git's rebase command to people who *very obviously are not using Git* and who are equally obviously *not interested in learning or using Git*, then your attitude does, in fact, reek. You want the feature. We don't. It's kind of up to *you* to explain to *us * (in *our* terms!) why it's important and how it doesn't undermine the very point of Fossil's design. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Fossil vs. Git/Mercurial/etc.?
Michael Richter decía, en el mensaje "Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?" del Domingo, 30 de Diciembre de 2012 02:11:46: > There's use cases for every bizarre feature in every bizarre SCM (distributed > or otherwise) out there. Let's not turn Fossil into the C++ of DSCMs, shall > we? If you *really, positively, /absolutely/* must have rebase, Git is > that-a-way. Insisting that Fossil should turn into Git is not a viable > argument. *standing ovation* -- o-=< Marcelo >=-o ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter wrote: > On 30 December 2012 12:56, Nico Williams wrote: >> >> What is it about rebase that causes so many to miss the idea of a >> rebase that is NOT destructive because it creates a new branch instead >> of doing a destructive change to an existing branch? > > I don't know. You won't explain it. "It's too much work," remember? You had left me under the impression that you knew what git rebase is. Fair enough, here we go: A "rebase" operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since then b) creates a new line of commits that consists of plus the commit set computed in (a), each commit in that set applied as a delta onto , merging as needed. So, if we have a branch called "trunk" with this history: A---B---C---D and a branch called "new-feature" with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. In *git* this is a destructive operation because the new-feature branch's HEAD is made to be c', which is not a linear history from c. But if the rebase operation creates a new branch whose HEAD points to c' then there's nothing destructive. Other things that can be redone in a rebase would include: A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) A---B---C---D---a'---c' (drop a commit, not merely change the base of a) A---B---C---D---abc' (merge all three of a, b, and c, into abc') A---B---C---D---ac'---b' (re-order and merge some) A---B---C---D---a1'---a2'---b'---c' (split a and rebase) A---B---C---abc' (no rebase, just merge the top three commits) These are things that upstream maintainers of large projects quite often insist upon. 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] Fossil vs. Git/Mercurial/etc.?
On 30 December 2012 13:23, Nico Williams wrote: > A "rebase" operation takes a branch (typically the current one) and > two commits (oldbase and newbase) in the repository and then a) > computes the set of commits that are in the branch since > then b) creates a new line of commits that consists of plus > the commit set computed in (a), each commit in that set applied as a > delta onto , merging as needed. > And why would I want to do this? Explain as you would to, say, a small child. > So, if we have a branch called "trunk" with this history: > > A---B---C---D > > and a branch called "new-feature" with these commits > > A---B---C---a---b---c > > where commits a, b, and c are in the new-feature branch but not in > trunk, and clearly we're missing commit D from trunk in new-feature, > we want to end up with: > > A---B---C---D---a'---b'---c' > > Where a', b', and c' are each based on commits a, b, and c, but merged > onto D. > Why not, for example, just merge c into D or vice versa? I really don't see what modifying history does here. Possibly because I lack the imagination to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this would be a desirable feature. Could you be more specific? A---B---C---D---a'---c'---b' (re-order commits, not merely change the > base of commit a) > Why? > A---B---C---D---a'---c' (drop a commit, not merely change the base of a) > Why? > A---B---C---D---abc' (merge all three of a, b, and c, into abc') > Why? > A---B---C---D---ac'---b' (re-order and merge some) > Why? > A---B---C---D---a1'---a2'---b'---c' (split a and rebase) > Why? > A---B---C---abc' (no rebase, just merge the top three commits) > Why? > These are things that upstream maintainers of large projects quite > often insist upon. > And why do they do this? I kinda/sorta get the mechanism. I just don't see the motivation. (And "upstream maintainers insist upon this" is not motivation, it's just moving the question of motivation around.) -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter wrote: > On 30 December 2012 13:23, Nico Williams wrote: >> >> A "rebase" operation takes a branch (typically the current one) and >> two commits (oldbase and newbase) in the repository and then a) >> computes the set of commits that are in the branch since >> then b) creates a new line of commits that consists of plus >> the commit set computed in (a), each commit in that set applied as a >> delta onto , merging as needed. > > > And why would I want to do this? Explain as you would to, say, a small > child. Short version: because upstream tells you to. Longer version: first because upstream wants patches that apply cleanly, but if you don't have commit D in the new-feature branch and your commits a, b, and/or c require merging with D, then the upstream will tell you to update your patches (it's *your* job to do such merges), second because upstream may want you to re-organize your work (as I've explained before; no need to repeat). >> >> So, if we have a branch called "trunk" with this history: >> >> A---B---C---D >> >> and a branch called "new-feature" with these commits >> >> A---B---C---a---b---c >> >> where commits a, b, and c are in the new-feature branch but not in >> trunk, and clearly we're missing commit D from trunk in new-feature, >> we want to end up with: >> >> A---B---C---D---a'---b'---c' >> >> Where a', b', and c' are each based on commits a, b, and c, but merged >> onto D. > > > Why not, for example, just merge c into D or vice versa? I really don't see > what modifying history does here. Possibly because I lack the imagination > to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this > would be a desirable feature. Could you be more specific? Because D is already upstream, therefore to remove D from upstream would be a destructive operation. The goal is to produce new commits that apply cleanly to trunk upstream. Again, if I send a, b, and c upstream and D was missing in my branch then my commits may not apply cleanly. Even if they do the commit hashes will change as in the upstream the parent of a will be D, not C. >> A---B---C---D---a'---c'---b' (re-order commits, not merely change the >> base of commit a) > > > Why? Because upstream may ask for it. For example, if I wrote a test first, committed it, then a bug fix -- my mistake, but I should have done it the other way around (though I might not have known the upstream maintainer's order preferences upfront). >> >> A---B---C---D---a'---c' (drop a commit, not merely change the base of a) > > > Why? Because it turns out that commit b was lame. Or because upstream decided to reject commit b but commits a and c still stood on their own. >> >> A---B---C---D---abc' (merge all three of a, b, and c, into abc') > > > Why? Because upstream thought these three belong as one. (E.g., b might fix a bug introduced by a, and c might fix a typo in b.) >> >> A---B---C---D---ac'---b' (re-order and merge some) > > > Why? Commit c might fix a typo in commit a, while commit b might be unrelated. Squashing (git term) c into a then helps keep history clean upstream. Upstream likes clean history in official repos. >> >> A---B---C---D---a1'---a2'---b'---c' (split a and rebase) > > > Why? Because commit a did two separable things and upstream wants them separated so that, for example, a1' can be pulled into an older release's bugfix branch without pulling in a2'. >> >> A---B---C---abc' (no rebase, just merge the top three commits) > > > Why? Here I'm not contributing abc' just yet. I'm still working but I know upstream wants commits a, b, and c merged. Eventually I'll have to rebase onto D, but I want to do that later. >> These are things that upstream maintainers of large projects quite >> often insist upon. > > And why do they do this? I kinda/sorta get the mechanism. I just don't see > the motivation. (And "upstream maintainers insist upon this" is not > motivation, it's just moving the question of motivation around.) Because they want clean history. If commit b fixes a bug introduced by commit a then why should that bug -which had never been upstream to begin with- exist upstream in the middle of the history? Not only is there no reason to want that upstream, but having it upstream will only add to the burden of someone reviewing the history to understand it or specific changes in it. 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] Fossil vs. Git/Mercurial/etc.?
On 30 December 2012 14:00, Nico Williams wrote: > > And why do they do this? I kinda/sorta get the mechanism. I just don't > see > > the motivation. (And "upstream maintainers insist upon this" is not > > motivation, it's just moving the question of motivation around.) > > Because they want clean history. This is precisely why I maintain that you're not going to see a "rebase" in Fossil. Quoting from http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html: *There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second.* That's the "Voice of God" for Fossil speaking there. What you want is exactly not what Fossil was built to provide. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sun, Dec 30, 2012 at 12:09 AM, Michael Richter wrote:
> On 30 December 2012 14:00, Nico Williams wrote:
>> Because they want clean history.
>
>
> This is precisely why I maintain that you're not going to see a "rebase" in
> Fossil. Quoting from
> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html:
>
> There are differing philosophies here. Some say it is important to
> present a clean, linear narrative of what took place - a narrative
> that is easy to follow and easy to understand. Others say that it is
> more important to present history as it actually occurred, in all its
> messy detail, not how you wish it had occurred. Git and Hg tend more
> toward the first view whereas Fossil leans toward the second.
There's room for interpretation, and for persuasion.
Clearly the history in an official repo must reflect what happened.
But the history I choose to present in a contribution is entirely in
my hands to decide how it looks (and the upstream may impose their own
requirements). If it wasn't in the official repos, did it happen?
Fossil didn't always have private branched. It does now. Isn't that
a concession that sets precedent?
At Sun, for example, we had official repos for products ("gates"),
project repos aiming at eventual integration into product gates, and
individual repos. Individuals pushed to either project gates or
product gates, depending on what they were working on. Product gates
were always archived and available, even for ancient releases of the
products. Project gates were generally (but not always) archived and
available. Individual repos were generally littered across the place,
with no real way for one to find them without asking the developer
working on them. History was cleaned prior to pushing to gates higher
up the hierarchy, but past history in product gates was never
rewritten. This worked spectacularly well. Who wants to see typos
made and fixed before the commits landed on the product gates??
Answer: no one, because such things are useless and a burden.
The room I see for interpretation and/or persuasion lies in that not
all history is equally valuable.
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] Fossil vs. Git/Mercurial/etc.?
On Sun, Dec 30, 2012 at 12:19 AM, Nico Williams wrote: > There's room for interpretation, and for persuasion. That's one of the things that happen when we build religions: heresy. Is this heresy? You can't say. Maybe not even D. Richard Hipp can say. Unless I'm willing to fork fossil and do it my way (I'm not) and if D. Richard Hipp declares this heresy, then it's all academic. I would recommend a less religious approach though. Our thinking on technical matters evolves. Mine does. I hope yours does too. This isn't *real* religion. There's no moral principles at stake. Society is not at risk, not from this argument anyways. ___ 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] Fossil vs. Git/Mercurial/etc.?
On 30 December 2012 14:19, Nico Williams wrote:
> > There are differing philosophies here. Some say it is important to
> > present a clean, linear narrative of what took place - a narrative
> > that is easy to follow and easy to understand. Others say that it is
> > more important to present history as it actually occurred, in all its
> > messy detail, not how you wish it had occurred. Git and Hg tend more
> > toward the first view whereas Fossil leans toward the second.
>
> There's room for interpretation, and for persuasion.
>
Not really, no. Any interpretation that says anything other than "it is
more important to present history as it actually occurred" isn't
interpretation, it's dissembling.
> Fossil didn't always have private branched. It does now. Isn't that
> a concession that sets precedent?
>
I'd say the private branches pretty much eliminate your need for rebasing
entirely given what you've described as rebasing. Make your mess in your
private branches. Expose the pretty stuff in non-private branches.
Problem solved.
At Sun, for example, we had official repos for products ("gates"),
> project repos aiming at eventual integration into product gates, and
> individual repos. Individuals pushed to either project gates or
> product gates, depending on what they were working on. Product gates
> were always archived and available, even for ancient releases of the
> products. Project gates were generally (but not always) archived and
> available. Individual repos were generally littered across the place,
> with no real way for one to find them without asking the developer
> working on them. History was cleaned prior to pushing to gates higher
> up the hierarchy, but past history in product gates was never
> rewritten. This worked spectacularly well. Who wants to see typos
> made and fixed before the commits landed on the product gates??
> Answer: no one, because such things are useless and a burden.
>
So … have a public-facing "clean" repository and a private "dirty"
repository with private branches? Again, I don't see what screwing with
the DAG of the SCM buys you besides trouble.
--
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
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] Fossil vs. Git/Mercurial/etc.?
On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter wrote:
> On 30 December 2012 14:19, Nico Williams wrote:
>>
>> > There are differing philosophies here. Some say it is important to
>> > present a clean, linear narrative of what took place - a narrative
>> > that is easy to follow and easy to understand. Others say that it is
>> > more important to present history as it actually occurred, in all its
>> > messy detail, not how you wish it had occurred. Git and Hg tend more
>> > toward the first view whereas Fossil leans toward the second.
>>
>> There's room for interpretation, and for persuasion.
>
>
> Not really, no. Any interpretation that says anything other than "it is
> more important to present history as it actually occurred" isn't
> interpretation, it's dissembling.
But you're coming around, check it:
>>
>> Fossil didn't always have private branched. It does now. Isn't that
>> a concession that sets precedent?
>
>
> I'd say the private branches pretty much eliminate your need for rebasing
> entirely given what you've described as rebasing. Make your mess in your
> private branches. Expose the pretty stuff in non-private branches.
>
> Problem solved.
Sure! You came around, see?
Except that it's not easy to clean up history in private branches with
fossil. You have to manually cherry-pick each commit from one branch
onto another in the order that you want. Either splitting or merging
commits (forget which) is harder still. git gives you a nice
interface for doing this.
>> At Sun, for example, we had official repos for products ("gates"),
>> project repos aiming at eventual integration into product gates, and
>> individual repos. Individuals pushed to either project gates or
>> product gates, depending on what they were working on. Product gates
>> were always archived and available, even for ancient releases of the
>> products. Project gates were generally (but not always) archived and
>> available. Individual repos were generally littered across the place,
>> with no real way for one to find them without asking the developer
>> working on them. History was cleaned prior to pushing to gates higher
>> up the hierarchy, but past history in product gates was never
>> rewritten. This worked spectacularly well. Who wants to see typos
>> made and fixed before the commits landed on the product gates??
>> Answer: no one, because such things are useless and a burden.
>
> So … have a public-facing "clean" repository and a private "dirty"
> repository with private branches? Again, I don't see what screwing with the
Exactly. Nothing awful about that, is there.
> DAG of the SCM buys you besides trouble.
There... is no "playing around with the DAG of the SCM". A rebase is
just a new branch in this scheme. New branches are hardly "playing
around with the DAG of the SCM". This is true even in git -- the old
commits in the repo don't change, they're not even deleted -- the only
thing destructive git does in a rebase is change commit that a branch
name points to.
So if you want to go from
A---B---C---a---b---c
to
A---B---C---D---ac'---b'
you'll find that a, b, and c are still left behind. In fossil there'd
be a new branch name to refer to the line of commits headed by b'. In
git c is no unreachable, unless there was some other branch or tag
referring to it, but c is still in the repo, and if there's no other
way to reach it there's always the "reflog".
You seem to think that git rewrites history. It does not. The only
destructive actions in git are: changing what a branch or tag point
to, and pruning unreachable commits.
And yes, rebasing private branches is easy, except it's a very manual
task in fossil, so it's not easy.
___
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] Fossil vs. Git/Mercurial/etc.?
Nico Williams wrote: >On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote: So, for the third time, can you describe your proposed new feature >>>*without* saying the words "git" or "rebase". >>>No: it's too much work, and many people understand "git rebase", and >> -1. >So is that a -1 to the attitude, the proposal, or both? The proposal. It smells. Without a better description of the problem than "I need rebase", its impossible to do the evalutation of alternative solutions that good engineering practices call for to decide if the smell is an indication of a real problem or not. Minimally, knowing how you solve this problem using existing fossil commands would help decide if "to much work" is a valid evaluation, a straw man, an overlooked fossil feature, or a need for a minor workflow tweak. But technical descriptions of why things like perforce's three-step merge or mercurial queues or any other alternatives mentioned here aren't acceptable are pretty much required. Given a proper problem description, I'd be glad to do that for the ones I'm familiar with. I'd also be happy if you want to provide those, but expect that it's also "to much work". -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sun, 30 Dec 2012 14:40:27 +0800 Michael Richter wrote: > I'd say the private branches pretty much eliminate your need for > rebasing entirely given what you've described as rebasing. Make your > mess in your private branches. Expose the pretty stuff in > non-private branches. Private-branches are missing one, imho, important feature: ability to handle single branch. For now it's all or nothing which makes the above 'workaround' not so easy. Sincerely, Gour -- One is understood to be in full knowledge whose every endeavor is devoid of desire for sense gratification. He is said by sages to be a worker for whom the reactions of work have been burned up by the fire of perfect knowledge. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] Fossil vs. Git/Mercurial/etc.?
I should also point out that in the Sun model once every one or two bi-weekly mini-releases of the product gates the project gates would have to catch up. Catching up in a way that leaves project commits ahead of the product gate is effectively rebasing, which breaks child gates, which is bad. So what we did is we... created new project branches that got rebased to the upstream and then the child (individual) repos did the moral equivalent of "git rebase --onto" onto the new project gate branches. Note that history did not get re-written in the project gates: new branches appeared with similar, but different, history to their predecessors, but all stuck around forever. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams wrote: >On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter > wrote: >> On 30 December 2012 12:56, Nico Williams >wrote: >>> What is it about rebase that causes so many to miss the idea of a >>> rebase that is NOT destructive because it creates a new branch >instead >>> of doing a destructive change to an existing branch? >> I don't know. You won't explain it. "It's too much work," remember? >You had left me under the impression that you knew what git rebase is. > Fair enough, here we go: I thought I did, but then you said "rebase works on one branch." Except... >So, if we have a branch called "trunk" with this history: >A---B---C---D >and a branch called "new-feature" with these commits Uh, that's *two* branches! What happened to rebase working on one branch? But the crux of the issue is right here: >Other things that can be redone in a rebase would include: >From what you've said, I believe that it's these *other things* that you want: >an easy way to munge commits as they get copied to a new branch. I don' think >that's an unreasonable request, as opposed to wanting rebase. After all, we >can do that now with repeated cherry-picking merges. But without a more >detailed description than "I want rebase", it's hard to tell if that's the >case or not, propose alternatives, and otherwise engage in the process of >refinement that peer review is supposed to provide. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
