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 <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. >>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
