On Jun 15, 2018, at 4:46 PM, Stephan Beal wrote:
>
> - refactoring to a lib is a huge effort.
That’s the real trick, I think: the library needs to be part of Fossil proper,
so that it stays up to date.
That in turn means finding and maintaining a strong boundary between whatever
your
i will write a longer response when i'm back on the PC, but short version:
- refactoring to a lib is a huge effort.
- up until late 2014 i was actively working on a library port and had most
of the core features working.
- RSI struck me down and has since effectively removed me from the
Yup! Looks good. (I read the whole thread, but this seemed like best
message to which to reply. I think Jungle-Boogie's comment about being able
to accept directly from the UI for things like text updates would be
great... but it could be added later.)
Will need a bit of documentation to help
On Fri, 15 Jun 2018 16:44:55 -0400
Richard Hipp wrote:
> Other ideas for what to name this (hypothetical and unimplemented) command:
>
>fossil contribute
>fossil bequest
>fossil bestow
>fossil proffer
>
fossil propose
--
http://fresh.flatassembler.net
http://asm32.info
John
On 6/15/18, Richard Hipp wrote:
> On 6/15/18, Chad Perrin wrote:
>>
>> This would not technically be a "pull request". It would be a "merge
>> request".
>
> Good point. It should not be called "pull-request" as pulling does
> not come into play.
>
> On the other hand, it is not necessary a
On 6/15/18, Chad Perrin wrote:
>
> This would not technically be a "pull request". It would be a "merge
> request".
Good point. It should not be called "pull-request" as pulling does
not come into play.
On the other hand, it is not necessary a request to merge. Often a
merge is implied, but
First post. Hi!
I've been lurking along, following the discussion here.
Common thread is a desire for 'more fossil'. I'm in this camp myself.
But I see the attraction of the core fossil application. It works perfectly
for a fairly close-knit community, and it follows a philosophy that's been
It looks good to me.
Actually, implementation details doesn’t really matter as long as it’s
easy to contributors to push a “pull-request” (however we call it), easy
for admins to check it (being able to do it also via the UI would be
very nice) and accept or refuse it, and if it doesn’t make
On Fri, Jun 15, 2018 at 01:35:13PM -0400, Richard Hipp wrote:
>
> An alternative design sketch:
>
> (1) Anonymous clones repo CoolApp
>
> (2) Anonymous makes changes to CoolApp and checks those changes into a
> branch named "anon-patch" on her private clone. Repeat this step as
> necessary to
On Fri, Jun 15, 2018 at 12:55:34AM +0100, Thomas wrote:
> On 2018-06-15 00:32, Chad Perrin wrote:
> >> Pull requests are not supported, hence the software can't be used for
> >> community driven open source.
> >
> > The pull request interface on GitHub is a feature of GitHub, not of Git.
> >
On Fri, Jun 15, 2018 at 09:27:31PM +0200, Nicola Vitacolonna wrote:
> On 15/06/2018 01:32, Chad Perrin wrote:
> > On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote:
> >>
> >> Pull requests are not supported, hence the software can't be used for
> >> community driven open source.
> >
> >
On 6/15/18, Nicola Vitacolonna wrote:
>> Git does have its own method (`git am`).
>
> Sorry, that should be `git request-pull`.
From the manpage, it appears that the "git request-pull" command is
less automatic than my proposed "fossil pullrequest" command. The
git-request-pull expects the
> Git does have its own method (`git am`).
Sorry, that should be `git request-pull`.
Nicola
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 6/15/18, Ron W wrote:
> On Fri, Jun 15, 2018 at 2:58 PM,
>
> wrote:
>
>>
>> Date: Fri, 15 Jun 2018 13:35:13 -0400
>> From: Richard Hipp
>> Subject: Re: [fossil-users] Perception of Fossil
>>
>> An alternative design sketch:
>>
>> (4) The pullrequest command creates a "bundle" out of the
On 15/06/2018 01:32, Chad Perrin wrote:
> On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote:
>>
>> Pull requests are not supported, hence the software can't be used for
>> community driven open source.
>
> The pull request interface on GitHub is a feature of GitHub, not of Git.
> While
On Fri, Jun 15, 2018 at 2:58 PM,
wrote:
>
> Date: Fri, 15 Jun 2018 13:35:13 -0400
> From: Richard Hipp
> Subject: Re: [fossil-users] Perception of Fossil
>
> An alternative design sketch:
>
> (4) The pullrequest command creates a "bundle" out of the "anon-patch"
> branch and then transmits that
On 6/15/18, jungle Boogie wrote:
>
>> Additional notes:
>>
>> Prior to step (3), Fossil might require Anonymous to provide contact
>> information so that developers can get in touch in case there are
>> questions or requests for clarification. Anonymous might also be
>> asked to sign a
On Thu, Jun 14, 2018 at 08:17:47PM -0600, Warren Young wrote:
>
> Back when I proposed the feature set that became bundles, I proposed
> that it include a way for the outside contributor to create a ticket
> from a bundle, which would be pushed to the remote repository for
> disposition by
On Fri, Jun 15, 2018 at 11:32:41AM +, Pietro Cerutti wrote:
>
> Oh so it looks they don't offer proper mailing lists (the ones people
> can subscribe and reply to) but only newsletters, which they call
> mailing lists, so sorry for the noise and my confusion.
I also worked on a project for
On Thu, Jun 14, 2018 at 5:20 PM,
wrote:
>
> Date: Thu, 14 Jun 2018 15:12:17 -0600
> From: Warren Young
> Subject: Re: [fossil-users] Perception of Fossil
>
> On Jun 14, 2018, at 2:51 PM, Ron W wrote:
> >
> > In another forum I follow,a commented claims that Fossil is designed for
> "cathedral
All very, very lovely thinking! I just have one comment/question...
On 15 June 2018 at 10:35, Richard Hipp wrote:
> On 6/15/18, David Mason wrote:
>> I heartily agree with this... A flag to allow a person (including
>> Anonymous) to make a commit that would automatically go into a new branch
>>
On 6/15/18, David Mason wrote:
> I heartily agree with this... A flag to allow a person (including
> Anonymous) to make a commit that would automatically go into a new branch
> like "Patch-1" (each one incrementing the branch number) is (a) better than
> emailed patches, and (b) better than pull
On Fri, 15 Jun 2018 15:23:42 +0200
"Olivier R." wrote:
> When someone clones the repo, make one or several commit(s), then push
> to the repo without having the right to change it, this commit could be
> queued somewhere (in a temporary branch maybe?), then the
> administrator(s) may apply it
I heartily agree with this... A flag to allow a person (including
Anonymous) to make a commit that would automatically go into a new branch
like "Patch-1" (each one incrementing the branch number) is (a) better than
emailed patches, and (b) better than pull requests. Primarily because it
puts it
Le 15/06/2018 à 01:32, Chad Perrin a écrit :
On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote:
Pull requests are not supported, hence the software can't be used for
community driven open source.
The pull request interface on GitHub is a feature of GitHub, not of Git.
While it would be
On Jun 15 2018, 07:51 UTC, Pietro Cerutti wrote:
On Jun 14 2018, 13:05 UTC, Richard Hipp wrote:
On 6/13/18, Richard Hipp wrote:
Unfortunately, I'm going to need to shut down this mailing list due to
robot harassment. I am working to come up with a fix or an
alternative now
Mailing
On Jun 14 2018, 13:05 UTC, Richard Hipp wrote:
On 6/13/18, Richard Hipp wrote:
Unfortunately, I'm going to need to shut down this mailing list due to
robot harassment. I am working to come up with a fix or an
alternative now
Mailing lists are now back on-line and once again accepting
27 matches
Mail list logo
