On 31 December 2012 04:41, Mike Meyer <[email protected]> wrote: > > > Nico Williams <[email protected]> wrote: >>Go back through those 30 posts you mentioned. Go back to the very >>first one from me. I tried to be concise and wrote just three >>paragraphs that, IMO, captured what was needed. I certainly did not >>say "I want git rebase in fossil" and then watched the fireworks -- >>no, I explained *concisely* (or at least that was my aim). > > No, you said "I want something slightly different than git rebase in fossil." > Concise? Yes. Precise? No. Well-defined? No. Useful? No. > >>If I had written a ten-page post explaining in excruciating detail >>what rebase is, why it matters, and how to adapt it to the Fossil >>philosophy, who -but who!- would have read that first post? I was >>being (I thought!) considerate. And judging by last night's 30 posts, >>would it have made any difference to post a thesis-length argument for >>rebase? And if so, how was I to know that? Or should I have given up >>at the very first sign of trouble? > > That depends on the goal. If you want to troll the list, then arguing for > rebase is a good choice. If you want fossil to incorporate a solution for > your problem, you should provide the information people are asking for. Given > how poorly your attempt to work with the comunity has gone, giving up now > isn't an unreasonable option. On the other hand, if you want to be able to > use fossil, and are willing to work with us to solve your problem instead of > arguing about what "rebase" does, you can start by answering our questions. > > For instance, you haven't answered any of my questions. You've explained in > detail what rebase does, but that's irrelevant, because rebase is only an > approximation to what you want, and you haven't explained how what you want > is different in sufficient detail for us to figure out what that is. You > haven't shown us why the existing solutions are "to much work". You haven't > said what kind of interface you want (otherr than "interactive rebase", and > you haven't said what that interface looks like!). You may think you have, > but your opinion here doesn't matter: if we don't have a clear understanding > of what you want, we don't have it, and the onus is on you to provide it. The > best way to do that is by answering our questions.
Rebase is a mass cherry-pick script, basically. You have an upstream trunk U and you branch B and in the simplest form rebase cherry-picks every single commint in B from the branching point to the tip one by one on top of U and marks the result as B. As has been pointed out this marking the result as B is the only destructive part which loses the original B and is unnecessary. Now the more involved version allows you to control how commits are picked. rebase presents you with a rebase recipe which shows the list of commits in B and all are marked with the default 'pick' which results with the above basic behaviour. You can edit the recipe to drop some commits, change the order in which they are picked, mark some for editing so rebase stops on them, mark some for squashing so rebase folds them into the previous commit. You can even select if the commit message of the squashed commit is appended or dropped but to edit the resulting message you have to run rebase again and mark for edit. Git add comes with a tool which allows you to pick only some files or some hunks from the checkout when creating a commit. It just shows the changed files and the hunks in the picked files one by one and asks you which to add. Sadly this tool is quite poorly integrated in git. When cherry-picking this cannot be used. To actually split a commit during rebase you have to mark the commit for editing, undo it, and then add parts of that commit as multiple commits possibly using the interactive add tool. When the commit adds files this is very error-prone. You can see that these tools are not available in fossil and with its web interface they could be presented in more friendly way than what the git commandline tools present. You can also see that while git has them they are not quite stellar. Thanks Michal _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
