Nico Williams <n...@cryptonector.com> 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 <m...@mired.org> wrote: >> Nico Williams <n...@cryptonector.com> 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
