On Mon, Mar 2, 2015 at 6:30 AM, Richard Hipp wrote:
> Ben Pollack's essay at
> http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/
> succinctly points up some of the problems with DVCS versus centralized
> VCS (like subversion). Much further discussion occurs on the vari
On Sun, Dec 7, 2014 at 12:35 PM, Stephan Beal wrote:
> On Sun, Dec 7, 2014 at 6:55 PM, wrote:
>>
>> The problem: A (mostly) text file with just a few normally non-text chars
>> which confuse fossil into thinking the whole file is binary.
>
>
> There's an irony in there somewhere. It can't be part
On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal wrote:
> No, he can't. Well, he can, but he will break the hashes of other records,
> so any tamping will be noticed. Specifically, the Z- and R-cards detect any
> sort of tampering.
Right. He can. If you've not pushed the commits anywhere else bef
On Thu, Sep 11, 2014 at 11:18 AM, Richard Hipp wrote:
> On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams
> wrote:
>> Nothing can really be made immutable, but you can detect mutation.
>
> No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6
> release) cann
On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp wrote:
> On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams
> wrote:
>>
>> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp
>> > On the few cases when this has happened to me, I've moved "goof" into a
>&
On Thu, Sep 11, 2014 at 10:18 AM, John Long wrote:
> On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote:
>> On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams wrote:
>>
>> > > git branch -D name
>> >
>> > Eh, filesystems let you delete files
On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp wrote:
> On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland wrote:
>> On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp wrote:
>>> Sometimes we will make a check-in to trunk then later decide it doesn't
>>> belong there, so then move it into a branch. (
>>
On Sat, Sep 06, 2014 at 10:22:13AM +0200, Stephan Beal wrote:
> On Fri, Sep 5, 2014 at 10:03 PM, Nico Williams
> wrote:
> > To me the "designed to forget" comments seem like a
> > stretch.
> >
>
> git branch -D name
Eh, filesystems let you delete files
On Mon, Sep 1, 2014 at 10:29 AM, Stephan Beal wrote:
> Okay, more git bashing...
Seems like a lot of the complaints are the sorts of complaints you
would get about -say- laptops:
- it's easy to forget you left something on your laptop two flights
ago, when you had no connectivity, and forgot to
On Tue, Sep 2, 2014 at 6:47 PM, Richard Hipp wrote:
> (3) Create a new "fossil bundle import" command that imports a bundle as a
> *private* branch.
Require a branch name as an argument and there will be no need to
think about branch name collisions.
It doesn't matter that the branch namespace i
On Sat, Jul 26, 2014 at 10:04 PM, Eric Rubin-Smith wrote:
> Richard Hipp wrote:
>> Fossil can give you the ticket data as SQL. I think that is probably
>> about as portable as ticket data is going to get.
+1
> ... says the top SQL expert between here and the Romulan Neutral Zone. :-)
But it's
On Mon, Jun 16, 2014 at 11:49 PM, B Harder wrote:
> Remember that the buffer is only one level deep, though. A subsequent ^W, ^K
> , etc will clobber the previous contents.
>
> Along lines of Stephan Beals method, I use ":" preceding the fossil command.
> So:
>
> $ : fossil ci -m 'some msg'
>
> ("
On Thursday, June 12, 2014, JR wrote:
> I will avoid the rant I had just written and simply say that I do not use
> cmd.exe except where required. I use PowerShell exclusively, which makes
> cmd.exe look like the ancient tool it is, and there are debates that
> PowerShell is better than bash due
On Sun, Jun 8, 2014 at 7:15 PM, Ron Wilson wrote:
> On Sat, Jun 7, 2014 at 8:37 PM, Nico Williams wrote:
>> The same is true for git, and Mercurial, and... It doesn't mean it
>> can't be done, just that the VCS has to know how to canonicalize the
>> file's co
On Sat, Jun 7, 2014 at 1:32 PM, Stephan Beal wrote:
> It's unfortunately not a "minor technical issue" because of how fossil
> calculates the hash for the whole contents of a repository for
> ...
The same is true for git, and Mercurial, and... It doesn't mean it
can't be done, just that the VCS
On Saturday, June 7, 2014, Andy Bradford <
amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org> wrote:
> Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500:
>
> > I should add that it's not always possible or desirable to test all
> > commits in
I should add that it's not always possible or desirable to test all
commits in a bundle that will be pushed together. A goal of breaking
up large commits into smaller ones is to make it easier to understand
and backport them, but an engineer working on a backport will have to
retest anyways. Also
On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo
wrote:
> I'm not Nico, but allow me answer that as well.
>
> When I was learning to use git, my teacher told me:
> "When you have a set of changes where a peace of code requires another
> peace, you must commit all that together. But if
On Thu, Jun 5, 2014 at 7:58 PM, Richard Hipp wrote:
> On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams wrote:
>>
>> On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland wrote:
>> > foo.txt has changes A, B, C and D.
>> >
>> > After each change the develop
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland wrote:
> foo.txt has changes A, B, C and D.
>
> After each change the developer had the foresight to do a "fossil stash
> snapshot". Now the developer decides to put changes B and D into branch b-d
> and keep changes A and C on the trunk:
Ah, foresight
On Thu, Jun 5, 2014 at 10:36 AM, B Harder wrote:
> drh> Fossil allows you to commit a subset of files (by listing the
> files on the "fossil commit" command line) but there is no mechanism
> for committing a subset of lines within a single file.
>
> That, and there _are_ branches/tags which are en
On Wednesday, June 4, 2014, Alysson Gonçalves de Azevedo <
agalys...@gmail.com >
wrote:
> I started to use fossil just today, but let me participate too :)
>
> Everyday I have a list of tasks that I have to work on and when I finish,
> I like to separate the changes of each task by commit.
>
> To
On Wed, Jun 4, 2014 at 1:34 PM, Richard Hipp wrote:
> On Wed, Jun 4, 2014 at 2:20 PM, Nico Williams wrote:
>>
>> I never need to diff the staging area to the HEAD. Only the workspace
>> to the HEAD+staging area, which is what git diff does.
>
>
> Huh. I didn'
sent too soon.
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp wrote:
> The staging area is another element of state on a check-out. It is one more
> thing that the developer must keep in mind. Better to minimize the amount
> of "mind-space" required for the VCS in order to leave as much mind-spa
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp wrote:
> On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams
> wrote:
>> Right, the index is a very light-weight mechanism for giving the user
>> power in deciding what to commit. I.e., more fine-grained control
>> than &quo
On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal wrote:
> On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams wrote:
>>
>> To be truly useful it has to be possible to [selectively] push/pull
>> bookmarks.
>
>
> If that's the case then they really provide no benefits
On Wed, Jun 4, 2014 at 12:02 PM, Richard Hipp wrote:
> On Wed, Jun 4, 2014 at 12:53 PM, B Harder wrote:
>>
>> Indeed, non-propagating tags are also "checkout-able" items.
>>
>> What am I missing about bookmarks that we can't already enjoy w/ tags,
>> outside of new syntax ?
>
> Here's something t
On Wed, Jun 4, 2014 at 12:24 PM, Stephan Beal wrote:
> In the core, basically the only addition would be adding another block to
> symbolic_name_to_rid(), which simply expands the "..." part from "bk:..."
> from the bookmark list, then runs that result through through
> symbolic_name_to_rid(). Tha
On Wed, Jun 4, 2014 at 11:53 AM, B Harder wrote:
> Indeed, non-propagating tags are also "checkout-able" items.
>
> What am I missing about bookmarks that we can't already enjoy w/ tags,
> outside of new syntax ?
In git, tags and branches are both very light-weight bookmark-like concepts.
The di
On Wed, Jun 4, 2014 at 11:15 AM, Stephan Beal wrote:
> On Wed, Jun 4, 2014 at 6:03 PM, Nico Williams wrote:
>> On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal
>> wrote:
>> > Bookmarks. That's a nice idea, actually. Added to my TODO list.
>
> i was thinking more g
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal wrote:
> On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams
> wrote:
>> Mercurial too had "heavy-duty" branches only, then they added
>> "bookmarks" that are very similar to git branches. Since a "bookmark"
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal wrote:
> On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams
> wrote:
>> You're mixing things up :) Rebase is just a script around "new branch
>> starting at given base, cherry-pick all the commits from the base to
>>
On Tue, Jun 3, 2014 at 4:15 PM, Stephan Beal wrote:
> On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams
> wrote:
>> git rebase... doesn't remove commits from the repo. It only creates
>> new commits and then updates a branch's head to point to the newest of
>>
On Tue, Jun 3, 2014 at 3:26 PM, Stephan Beal wrote:
> On Tue, Jun 3, 2014 at 10:05 PM, Nico Williams
> wrote:
>>
>> These aren't architectural changes.
>>
>> For example, rebase == scripted sequence of cherry-picks. The index
>> is more architectural
On Tue, Jun 3, 2014 at 2:03 PM, Stephan Beal wrote:
> On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams wrote:
>>
>> Being able to round-trip this way might allow more users to test-drive
>> Fossil.
>
>
> It's not possible due to the limitations of round-trippi
On Tue, Jun 3, 2014 at 1:07 PM, Nico Williams wrote:
> On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal wrote:
>> FWIW: Fossil was never intended to be a round-trip safety hatch for other
>> SCMs which aren't as data-robust. Maybe convince the git developers to move
>>
On Tue, Jun 3, 2014 at 1:32 PM, Andy Bradford
wrote:
> Thus said Nico Williams on Tue, 03 Jun 2014 11:42:44 -0500:
>
>> - the date (Fossil changes the timezone to +, that is, it loses
>> the timezone of the original).
>
> Timestamps in Git are UTC and have no time
On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal wrote:
> My point being: at least some small percentage of round-trip timestamp
> conversions will fail because Julian Days to not have a 1-to-1 mapping for
> all millisecond-level ranges in use today.
Yes, though perhaps Fossil could store the Date (
So git doesn't handle power failures so well... And Fossil's use of
SQL, and SQLite3 in particular, is awesome. But my colleagues and I
like git workflows, and anyways we have git repos we can't just
migrate to Fossil. The obvious idea is to use a git post-receive hook
to backup git to Fossil, w
On Sun, Jun 1, 2014 at 5:56 AM, Dömötör Gulyás wrote:
> On 1 June 2014 06:43, B Harder wrote:
>> http://mikegerwitz.com/papers/git-horror-story
>
> An interesting scenario, what is there to be learned from it for
> fossil? Since fossil doesn't like history rewrites, are we protected
> to some deg
On Mon, Feb 17, 2014 at 4:26 PM, Stephan Beal wrote:
>> In which case I'd strongly urge that the best option here is to pick a
>> third party servlet engine based on its own criteria rather than
>> inventing yet another one --- they're harder than they look and there
>> are too many as it is! (Par
On Fri, Feb 7, 2014 at 11:40 AM, Stephan Beal wrote:
> On Fri, Feb 7, 2014 at 6:15 PM, Ron Wilson wrote:
>>
>> I am guessing this is a limitation of SQLite, which is designed to be
>> "light". It would be interesting to see how Fossil would perform when
>> "plugged in" to, for example, PostgreSQL
On Thu, Jan 2, 2014 at 8:50 PM, Richard Hipp wrote:
> On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer wrote:
>> * Richard Hipp:
>>
>> > The silly requirement of some distributions that *everything* must be a
>> > shared library irks me beyond words. [...]
>>
>> Uhm, does POSIX file locking work c
On Thu, Jan 2, 2014 at 4:28 PM, Florian Weimer wrote:
> * Richard Hipp:
>> The silly requirement of some distributions that *everything* must be a
>> shared library irks me beyond words. I hate having to support
>> --disable-internal-sqlite, and I hate having to add silly work-arounds in
>> the c
On Tue, May 28, 2013 at 10:25 AM, Richard Hipp wrote:
> If you forget to do it then, you can always visit a check-in after it is
> committed and click on the "Edit" link to do things like revise the check-in
> comment, update the check-in time, or move the check-in to a different
> branch (such as
On Fri, Mar 29, 2013 at 6:55 AM, Richard Hipp wrote:
> What else is needed?
You'll also need:
- user and repo mgmt interfaces
If you grow you'll want a search facility (search multiple repos),
edit via browser UIs, ... Like github, basically.
Nico
--
_
On Fri, Mar 29, 2013 at 6:55 AM, Richard Hipp wrote:
> Suppose I did write my own hosting system. What is is required for that.
> (James, you have the most experience with this question, so your input is
> especially encouraged!)
>
> (1) Some means for people to create accounts
There are many
On Thu, Jan 31, 2013 at 3:28 PM, Stephan Beal wrote:
> On Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user
> wrote:
>>
>> bld/shell.o: In function `find_home_dir':
>> ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
>> applications requires at runtime the shared libraries from the
On Thu, Jan 31, 2013 at 3:19 PM, K. Fossil user
wrote:
> $ ./configure --prefix=/usr --sysconfdir=/etc \
> --with-openssl=auto \
> --json \
> --markdown
> $ make
> ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
> applications requires at runtime the shared libraries from the
On Wed, Jan 30, 2013 at 2:58 PM, Stephan Beal wrote:
> On Wed, Jan 30, 2013 at 8:45 PM, Sergei Gavrikov
> wrote:
>>
>> Incidentally, there is another opinion, Never use static linking!
>>
>> http://www.akkadia.org/drepper/no_static_linking.html
>
>
> On a related note, Solaris 10 removed static
https://chiselapp.com/user/nico/repository/nico
Two branches: rebase, and test-rebase.
This adds a --nocommit option to the fossil merge command that does...
what it sounds like it does: it applies the patch from a --cherrypick
commit and leaves that uncommitted.
I applied all the commits from m
On Jan 3, 2013 12:13 PM, "Richard Hipp" @
sqlite.org > wrote:
>
>
>
> On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym
>
@snell- pym.org.uk >
wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 12/31/2012 09:33 AM,
You could just compute throw away mnodes and just cache that. Fossil
already has a cache, no?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
There used to be a VCS called PRCS. It had no network support, but aside
from that it was awesome, partly because every file was assigned an
"mnode", which was roughly an analog of inode numbers, and this allowed
wonderful rename functionality. The same approach might work equally well
for Fossil
Thanks Mike, I appreciate this.
BTW, I now have a pretty good idea of what fossil rebase would look
like; the discussion was a success, largely thanks to Joerg's insight.
I've also started looking at src/merge.c to have an idea of how to
implement a version of fossil merge --cherrypick that doesn
On Mon, Dec 31, 2012 at 12:01 PM, Steve Havelka wrote:
> On 12/31/2012 06:21 AM, Jan Danielsson wrote:
>> On 12/31/12 11:17, Nico Williams wrote:
>> [---]
>>> But I feel I must at least address this
>>> insinuation that I was trolling.
>>It's obvi
On Sun, Dec 30, 2012 at 9:41 PM, Mike Meyer wrote:
> Nico Williams 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
[Sorry to break threading, but I unsubscribed, then saw this in the
archives and re-subscribed just to answer, but I don't have the
Message-ID.]
On Sun, Dec 30, 2012, Joerg Sonnenberger wrote:
>On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote:
> > I repeat: git r
On Sun, Dec 30, 2012 at 7:58 AM, Eric wrote:
> On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer wrote:
>>
>> Nico Williams wrote:
>
>>> Other things that can be redone in a rebase would include:
>>
>> From what you've said, I believe that it's t
I should also point out that in the Sun model once every one or two
bi-weekly mini-releases of the product gates the project gates would
have to catch up. Catching up in a way that leaves project commits
ahead of the product gate is effectively rebasing, which breaks child
gates, which is bad. So
On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter wrote:
> On 30 December 2012 14:19, Nico Williams wrote:
>>
>> > There are differing philosophies here. Some say it is important to
>> > present a clean, linear narrative of what took place - a narrative
>> >
On Sun, Dec 30, 2012 at 12:19 AM, Nico Williams wrote:
> There's room for interpretation, and for persuasion.
That's one of the things that happen when we build religions: heresy.
Is this heresy? You can't say. Maybe not even D. Richard Hipp can
say. Unless I'm willin
On Sun, Dec 30, 2012 at 12:09 AM, Michael Richter wrote:
> On 30 December 2012 14:00, Nico Williams wrote:
>> Because they want clean history.
>
>
> This is precisely why I maintain that you're not going to see a "rebase" in
> Fossil. Quoting from
> h
On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter wrote:
> On 30 December 2012 13:23, Nico Williams wrote:
>>
>> A "rebase" operation takes a branch (typically the current one) and
>> two commits (oldbase and newbase) in the repository and then a)
>> comput
On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter wrote:
> On 30 December 2012 12:56, Nico Williams wrote:
>>
>> What is it about rebase that causes so many to miss the idea of a
>> rebase that is NOT destructive because it creates a new branch instead
>> of doing
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote:
>>> So, for the third time, can you describe your proposed new feature
>>*without* saying the words "git" or "rebase".
>>No: it's too much work, and many people understand "git rebase", and
>
> -1.
So is that a -1 to the attitude, the proposal,
On Sat, Dec 29, 2012 at 10:49 PM, Michael Richter wrote:
> I'm pretty sure that "rebase" or its equivalents will never be a part of
> Fossil. Given that there are tools out there (like Git) that feature this
> functionality that some (and I stress it's only some) users want, perhaps
> this follow
On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer wrote:
> Nico Williams wrote:
>>You missed my proposal that a fossil rebase operation always copy the
>>branch being rebased and rebase that copy. It was in my very first
>>post on this thread:
>
> I didn't miss it. I
On Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell
wrote:
> Ah sorry, I was only talking about my objections against "git rebase". I don't
> know the best way to implement a feature that allows creating 'new history' at
> will (not destroying the old).
>
> All I can imagine sounds like a lot
On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote:
> You missed the point. Nothing should *ever* be rebased. It's a rewrite of
> history, which is a fundamentally bad thing. While a SCM should make
> generating patch files easy, it shouldn't require rewrites of history to do
> so.
You missed m
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
wrote:
> On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
>> And so on. Really. Large projects need order, they need process.
>> They need clean trees in official repos.
>>
>> Without a way to cle
On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
wrote:
> (top post, due to the complexity of the previous post)
>
> I've found many git-fans that are completely ashamed of how they develop. And
> they would never make public how they commit things (how they use the VCS), so
> they don't ac
On Sat, Dec 29, 2012 at 8:53 AM, Eric wrote:
> On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams
> wrote:
>
>
> Actually I agree with most of Mike Meyer's reply, but I wanted to pick
> this paragraph apart:
>
>> How many times have you submitted a patch to a
tl;dr: we agree that public history should not get rewritten. You
missed the point of when, where, and why I need rebase.
On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote:
> Nico Williams wrote:
>>Rebase is one of teh killer features of git.
>
> It certainly kills any int
Rebase is one of teh killer features of git; the other killer features
of git are in Fossil already, but rebase is not. And fossil adds its
own killer features: built-in web service, JSON RESTful API, wiki and
tickets integrated (and versioned, natch).
How many times have you submitted a patch to
IIUC the main reason to want a DLL instead of having to spawn a new
process for every operation is iOS. I hear that the dearth of
excellent git (and other) SCM clients for iOS has to do with the
constrained nature of the run-time environment.
___
fossil-
IMO this should be resolved per-server configuration. Consider the
risk of XSS attacks: simply treating all comments as text/plain
automatically mitigates any past XSS attack attempts. Granted, XSS
attacks are not very likely given that few users can be expected to
have commit access...
I would
If the robot runs in the context of a browser (as a plugin, say), then
using JS to populate href attributes becomes an irrelevancy: the robot
sees the DOM of the page as it would be rendered to the user.
Kees Nuyt's suggestion of a hidden link which disables the session
when followed strikes me as
On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell
wrote:
> I think that the git 'rebase' history rewriting could be stated different.
> Maybe the graph could be altered with fossil cards, the same way commit logs
> are
> changed. Then, "graph reworking" would not imply "history rewriting"
On Fri, Aug 17, 2012 at 11:24 PM, Stephan Beal wrote:
>> Let's put it this way. To return 200 for a POST that actually failed
>> is very strange -- the response entity had better, at the very least,
>> not be cacheable if you'll do that.
Arg, I meant 201 code.
> i would hope that no POSTs are c
On Fri, Aug 17, 2012 at 10:26 PM, Stephan Beal wrote:
> On Sat, Aug 18, 2012 at 5:17 AM, Nico Williams
> wrote:
>> What's not RESTful about it? At first glance I see it uses GET and
>> POST appropriately, not using GET to create things, using POST to
>> create/m
On Fri, Aug 17, 2012 at 7:03 PM, Stephan Beal wrote:
> On Sat, Aug 18, 2012 at 1:31 AM, Miles Fidelman
> wrote:
>> Is there any kind of RESTful API for accessing Fossil repositories?
>
> https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view
That's very nice. Thank
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 mer
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
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 c
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.
86 matches
Mail list logo
