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
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 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
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
[fossil-users] Something like rollback
My situation: * Working on a new feature. * Multiple files edited. * Notice a bug in another file, fix it. * Decide to commit just that file with the fix. * Type: fossil com -m "Small fix." [and crucially press enter by mistake before specifying the file name to commit] * ALL changes get committed (and synced) under the commit message "Small fix." Ideally I'd like to revert that commit somehow and do two smaller commits thereafter. Since there is no rewriting history in fossil, I assume that this would involve doing a new commit that is "the opposite" of the incorrect one, and then replying the changes one a time. How would I do this? -Nick ___ 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] Something like rollback
On 8/15/12 12:21 PM, Nick Zalutskiy wrote: Ideally I'd like to revert that commit somehow and do two smaller commits thereafter. Since there is no rewriting history in fossil, I assume that this would involve doing a new commit that is "the opposite" of the incorrect one, and then replying the changes one a time. How would I do this? I don't know the "right" answer, but having done this myself, this is what I do: edit the commit comment to better describe the "small fix" and then call the checkin of all of the other stuff as a "checkpoint" as part of building that other feature. I am paranoid and frequently do "checkpoint" checkins of a branch (typically trunk) even if the code is not yet properly working. I just want to capture the state of the world before anything bad happens. It's also a good way to get the stuff off of my local machine (in addition to the near real-time backups that are also happening, of course). -- michael at barrow dot me +1.408.782.4249 ___ 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] Feature request - Simpler way to add-remove files (in the web ui)
Hello, I think I just found out that it has been added recently (2012-08-07) on the to do list at: http://www.fossil-scm.org/index.html/wiki?name=To+Do+List Described as: Web-based file editing --- Simon Tremblay --- From: stm...@hotmail.com To: fossil-users@lists.fossil-scm.org Subject: Feature request - Simpler way to add-remove files (in the web ui) Date: Wed, 15 Aug 2012 01:08:06 -0400 Hello, I'm using Fossil for personal projects and would like to request a feature: A simpler way to add files without using a dos command prompt and a repository (if possible directly in the web ui with maybe something like buttons with a file browser or something like that) A simple interface with "Add file", "Add folder", "Remove file", "Remove folder" would make it really easier to add documentation to the wiki. I believe it would also expand its usability to non-technical people. Maybe that there are security reasons why it couldn't be implemented or it might be outside the scope of the system? Ideally a larger subset of functions available in the web ui would be great, but I believe these 4 would bring the most on the table. --- Simon Tremblay --- ___ 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] Something like rollback
On 8/15/12 12:21 PM, Nick Zalutskiy wrote: Ideally I'd like to revert that commit somehow and do two smaller commits thereafter. Since there is no rewriting history in fossil, I assume that this would involve doing a new commit that is "the opposite" of the incorrect one, and then replying the changes one a time. How would I do this? Hello, I'm not familiar enough with fossil to recommend you the best solution for your problem. But, an uncommit feature is currently in the fossil to do list at: http://www.fossil-scm.org/index.html/wiki?name=To+Do+List It has been added on 2012-08-07. --- Simon Tremblay --- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
