Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
On Wed, Aug 15, 2012 at 11:26 AM, Richard Hipp wrote: > On Wed, Aug 15, 2012 at 12:22 PM, Nico Williams > 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=A&to=D. > For example: > > http://www.sqlite.org/src/timeline?from=1e6f5ea&to=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:22 PM, Nico Williams wrote: > On Wed, Aug 15, 2012 at 5:48 AM, Richard Hipp wrote: > > On Wed, Aug 15, 2012 at 12:03 AM, Nico Williams > > 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? "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. > 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? > Point your webbrowser to http://project-domain/project/timeline?from=A&to=D. For example: http://www.sqlite.org/src/timeline?from=1e6f5ea&to=6954fe -- 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
On Wed, Aug 15, 2012 at 5:48 AM, Richard Hipp wrote: > On Wed, Aug 15, 2012 at 12:03 AM, Nico Williams > 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
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 12:03 AM, Nico Williams wrote: > On Tue, Aug 14, 2012 at 8:28 PM, Matt Welland 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
On Tue, Aug 14, 2012 at 8:28 PM, Matt Welland 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
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 wrote:
> 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 create
[fossil-users] Rebase is NOT fundamentally incompatible with Fossil
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 the branch names had "build"
numbers in them.
One nice aspect of this model is that it allows project and developer
gates to keep their commits "on top of" the upstream base branch: it's
always clear what local patches there are relative to the upstream.
Note that all these example use cases involve at least two individuals
(upstream and downstream), and examples #2 and #3 scale to very large
communities (experience at Sun certainly backs this up). That is,
these models scale all the way from two individuals to
