Nico Williams <n...@cryptonector.com> wrote: >On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter ><ttmrich...@gmail.com> wrote: >> On 30 December 2012 12:56, Nico Williams <n...@cryptonector.com> >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
