Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
On Wed, Aug 15, 2012 at 11:26 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 15, 2012 at 12:22 PM, Nico Williams n...@cryptonector.com wrote: Is there any way to request that the changes from a commit be merged into the workspace but not committed? fossil merge will only merge changes into the local checkout. You always have to do a separate fossil commit to add the merge results back into the repository. --cherrypick does not change this in any way. Ah, so, then the sequence to do a git-like rebase would be to make a list of commits, create a new branch, then for each commit run fossil merge --cherrypick each commit, review changes, fossil commit if desired (or not, if one wants to squash the next commit). Good! How would I get the list of commits that fossil merge D --baseline A would merge in? Point your webbrowser to http://project-domain/project/timeline?from=Ato=D. For example: http://www.sqlite.org/src/timeline?from=1e6f5eato=6954fe Is there any way to do this on the command-line? Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
On Wed, Aug 15, 2012 at 12:03 AM, Nico Williams n...@cryptonector.comwrote: On Tue, Aug 14, 2012 at 8:28 PM, Matt Welland estifo...@gmail.com wrote: I like the idea of cherry picking to a new branch. This would have nicely solved a few problems I've faced. I suppose you can kind of do this now using fossil cherrypick and manually creating the new branch but the There is a cherrypick command? Oh, it's an option to the fossil merge command. I had missed that entirely! The changes wiki page mentions something about allowing partial commits of cherrypick merges, but no details are given. How does this work? The --cherrypick option has been around for a long time. But formerly, if you did one or more --cherrypick merges into your checkout, then you would not be allowed to commit only some of the changes in your checkout using fossil commit FILE1 FILE2 When you commit just some of the files, we call that a partial commit. The recent change was to drop the restriction on partial commits following a cherry-pick merge. Note that the merge command also includes the --baseline option. The --baseline option can identify the start of a sequence of checkins that you want to merge. Suppose there are some sequence of changes in another branch A-B-C-D. If you do fossil merge D --baseline A, that would be the equivalent of doing three separate cherry-pick merges of B, C, and D, in that order. Note that the merge algorithm in Fossil does a good job of detecting redundant merges. So, in the example above, if you did a cherry-pick of C and later did a complete merge of the D branch, Fossil is likely to detect the redundant changes of C and do the right thing, without generating conflicts or warnings. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
Richard Hipp wrote: [...] Note that the merge command also includes the --baseline option. The --baseline option can identify the start of a sequence of checkins that you want to merge. Suppose there are some sequence of changes in another branch A-B-C-D. If you do fossil merge D --baseline A, that would be the equivalent of doing three separate cherry-pick merges of B, C, and D, in that order. Is this suitable for doing rewind/replay style modifications for, e.g., editing revision history? e.g. if I have A-X-B-C-D, and want to edit X, would I: - checkout A; - merge X with a different checkin comment; - merge D with a baseline of X? (I'm intending to end up with: A-X-B -C -D (closed) \-Y-B'-C'-D' .) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Parents let children ride bicycles on the street. But parents do not │ allow children to hear vulgar words. Therefore we can deduce that │ cursing is more dangerous than being hit by a car. --- Scott Adams ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
On Wed, Aug 15, 2012 at 5:48 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 15, 2012 at 12:03 AM, Nico Williams n...@cryptonector.com wrote: There is a cherrypick command? Oh, it's an option to the fossil merge command. I had missed that entirely! The --cherrypick option has been around for a long time. But formerly, if you did one or more --cherrypick merges into your checkout, then you would not be allowed to commit only some of the changes in your checkout using fossil commit FILE1 FILE2 When you commit just some of the files, we call that a partial commit. The recent change was to drop the restriction on partial commits following a cherry-pick merge. Is there any way to request that the changes from a commit be merged into the workspace but not committed? This would be necessary to implement some of the git interactive rebase options. Note that the merge command also includes the --baseline option. The --baseline option can identify the start of a sequence of checkins that you want to merge. Suppose there are some sequence of changes in another branch A-B-C-D. If you do fossil merge D --baseline A, that would be the equivalent of doing three separate cherry-pick merges of B, C, and D, in that order. How would I get the list of commits that fossil merge D --baseline A would merge in? Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
I like the idea of cherry picking to a new branch. This would have nicely solved a few problems I've faced. I suppose you can kind of do this now using fossil cherrypick and manually creating the new branch but the equivalency to the original edits is not preserved and merging back into a stream with the original edits will probably not work correctly in many cases. I'd give two thumbs up to this idea. On Tue, Aug 14, 2012 at 2:16 PM, Nico Williams n...@cryptonector.comwrote: Provocative Subject: line, I know. But it's true, git-like rebase is not incompatible with Fossil's principles *provided* that the result of a rebase is a new branch, or provided that the branch being affected has no children (i.e., that it's a private branch). I use git a lot, and I like it. I also like the ideas behind Fossil. I'm only really missing git cherry-pick and git rebase (which is based, really, on cherry-pick). Why rebase? I'd like to give you three example use cases where git cherry-pick and git rebase have been important to me. I hope that there are Fossil-specific alternatives, but if not then I hope that these examples will be useful to the Fossil community. Example #1: Rebasing commits in response to code reviews prior to upstream integration. Upstreams rarely ever want their canonical history polluted by a developer's typical missteps (typos, etcetera). See http://github.com:nicowilliams/krb5/branches, look for branches named kadm5_polic_exts*. Each one of these represents a rebase of another. That is, when I use git rebase I mostly do it in brand new branches so as to not be destructive of the original, even when all these branches are private as in this case. Each rebase was in response to code review comments. Some rebases I did in various sequences, first one to re-organize some commits (e.g., reorder, split, or squash them), then another to fix minor issues. Example #2: Cherry-picking from site-local feature branches onto site-local release branches. One SCM workflow I like involves maintaining sets of local patches to open source projects, with each patchset kept as local feature branches based on upstream release branches. To make a new site-local release from a new upstream release we first create a new site-local release branch for each site-local feature based on the new upstream release, cherry-pick/merge the given feature patches onto the new feature branches, test, then finally merge all the site-local feature branches onto a site-local release branch based on the new upstream release branch. git cherry-pick isn't essential here: git merge would suffice. But the cherry-pick concept allows more control over the merge metadata. Note that these site-local feature branches and site-local release branches are not always shared with the upstream (some hold patches that upstream does not want or which would be obviously of no interest to the upstream community), but they're not necessarily private in the sense of not being shared with other site-local repositories (e.g., developers'). Example #3: Intermediate upstreams (project gates). This example is very much based on how development was done at Sun Microsystems, and in all certainty still is at Oracle in groups acquired via the acquisition of Sun, and is how I do some development today for some customers. In this model we have upstream gates, project gates, and developer repositories. Developers branch off of project gates and push commits to the project gates. Project gates track upstream gates until the projects complete, at which point they push their changes upstream. You can surely see the problem though: as commits from multiple projects get pushed upstream each remaining downstream project gate has to rebase, and that breaks all their further downstream developers. Clearly this is broken. But there's a way to make this work, and we did this at Sun all the time: the rebases are done on new gates based on the old gates. In git this works as follows. First, the root upstream has a single canonical branch (master), the project gates are either branches off the canonical upstream branch, possibly in distinct repos, ditto the developer gates. Second, the project gates rebase periodically, each time creating a *new* branch and closing the previous project gate branch to new commits. Third, developers periodically rebase their branches onto (think of git rebase --onto=...) the new, rebased project gates. At Sun periodically meant specifically that we had build schedules that resulted in build releases, at which point a snapshot branch was created of the upstream root. Thus the periodic rebasing for the project gates was scheduled and
Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
On Tue, Aug 14, 2012 at 8:28 PM, Matt Welland estifo...@gmail.com wrote: I like the idea of cherry picking to a new branch. This would have nicely solved a few problems I've faced. I suppose you can kind of do this now using fossil cherrypick and manually creating the new branch but the There is a cherrypick command? Oh, it's an option to the fossil merge command. I had missed that entirely! The changes wiki page mentions something about allowing partial commits of cherrypick merges, but no details are given. How does this work? equivalency to the original edits is not preserved and merging back into a stream with the original edits will probably not work correctly in many cases. Cherry-picking is not destructive like rebase -- commits are only added. There's no need to make a cherry-pick operation create a new branch. The rebase operation is the one that is destructive in such a way that a new branch should be created as a result. As you note, a cherry-pick operation, and in particular one that has an option to leave the picked changes uncommitted, is the only building block necessary to implement rebase. After all, a rebase is just this series of steps: - make a list of commits from the old base to the current tip (or whatever Fossil calls HEAD/tip) - give the user a chance to edit the commit list (for interactive rebases only) - checkout the new base - create a new branch off the new base --- git doesn't do *this* - cherry-pick the commits from the list in the first step, merging as necessary (note that this can require user interaction, and note that the merge and interaction is really part of the cherry-pick operation) Of course, this would be best done in the fossil binary rather than in a script. Still, give me the cherry-pick operation as described above and I can script rebase. I'd give two thumbs up to this idea. Thanks. Anyone else I've failed to offend today? :) (I wasn't trying to offend... I'm really hoping that the idea of a COW rebase is as inoffensive as I think it is.) Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
