On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer <[email protected]> wrote: > > Nico Williams <[email protected]> wrote: <snip> >> 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.
So perhaps all we need is a streamlined way to do multiple cherry-picks (which may even end up with a similar feel to "git rebase --interactive"). Whatever we do we can't call it rebase, because people will then assume that it is just like git rebase, and it won't be because it must not manipulate the pre-existing tree. If you don't believe that the name matters, just read the "why does `fossil rm' not do the "real" thing?" thread. Now for a few more general comments (30 messages overnight!!): "Because upstream wants it" is not necessarily a good reason. Upstream can be just as misguided as downstream. Also they should not be making requests that are difficult in their VCS of choice, and likely workflows should have been part of the process of choosing a VCS. That commits should do only one thing is a sensible idea (whether the one thing is a one line bug fix or a major feature implementation), but this is about project policy, and developers should work in such a way as to be able to achieve it. You can do it in Fossil, and if something you have to do to achieve it "takes too long", then write, design, or ask for functionality to streamline it (in that order of preference!). One of the things that people seems to miss is that if you are working on several things in parallel (say a "nearly finished" feature, a feature in "early exploration", and a few bugs some of which are on different branches) you should really be doing each in a separate working directory based on the same repository. This is easy in Fossil, and is possible in git (or even CVS!). You will of course have to do various merges, but everything will be fairly clean, and you won't even need stash! Upstream will always have to do some merges! Someone on every project should have a clear idea of how branches can and should be used, and write a branching policy. Being sensible about branches and merges covers many of the apparent problems. And finally, if you want something that Fossil can't do at all, even in a round-about or tedious way, you need to be able to express it in terms of development needs, not just as "I want 'somevcs mangle'". Eric -- ms fnd in a lbry _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
