On 02.09.2014 23:49, David Given wrote:
> Given the discussion in the other thread(s), I have been thinking about
> pull requests. (I've also had a beer. You Have Been Warned.)
So the paperwork's finally come through and I'm able to work on this.
Hurray! Same disclaimer above applies.
I've put 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
Thus said Richard Hipp on Wed, 03 Sep 2014 10:51:10 -0400:
> For example, suppose the person wanting to generate the patch had
> actually cloned their clone of the repo, and done pushing and pulling
> between his two clones. Then the UNSENT table would have been emptied
> on both clones be
On Wed, Sep 3, 2014 at 10:39 AM, Andy Bradford
wrote:
> Thus said Andreas Kupries on Tue, 02 Sep 2014 15:23:33 -0700:
>
> > That information is part of a regular pull operation, so if we can
> > invoke only the steps to get that, without actually sending any
> > content back, then your
Thus said Andy Bradford on Wed, 03 Sep 2014 08:39:32 -0600:
> Is it as simple as taking the contents referenced in the unsent table
> and putting them into a mini Fossil that has just those artifacts (and
> perhaps any requisite predecessors).
Excluding any artifacts referenced in the private
Thus said Andreas Kupries on Tue, 02 Sep 2014 15:23:33 -0700:
> That information is part of a regular pull operation, so if we can
> invoke only the steps to get that, without actually sending any
> content back, then your new tool knows what the other side has.
Is it as simple as tak
On Wed, Sep 3, 2014 at 9:49 AM, Gour wrote:
>> (5) Create a new command and perhaps a new web page that will publish
>> (make public) a private branch or check-in. I don't yet know what
>> this command is called. ("publish"? Other suggestions?)
>
> 'publish' sounds good to me.
Other candidates
On Tue, 2 Sep 2014 19:47:14 -0400
Richard Hipp wrote:
> (2) Create a new "fossil bundle export" command that generates a
> "bundle" from a designated branch, or all check-ins following a
> particular check-in, or just a single check-in. The bundle format is
> an SQLite database file (essentially
Proposed plan of action:
(1) Modify "private" branch processing to avoid the "private" tag and
instead simply rely on the private artifacts residing in the PRIVATE table,
which should survive a "fossil rebuild". (A "fossil deconstruct; fossil
reconstruct" will make all private branches public sin
On Tue, Sep 2, 2014 at 3:36 PM, Ron W wrote:
> Your proposal for automatically calculating a list of commits to treat as
> already exported is a very good idea. Would definitely make the incremental
> export much easier to use.
>
> Your proposal to automatically strip (or rename) branch/tag info i
On Tue, Sep 2, 2014 at 5:49 PM, David Given wrote:
> I rather like the pull request workflow from github and Bazaar, and it's
> something that I rather miss from Fossil.
>
Last time I actualy used github (as opposed to simply getting the latest
sources for one thing or another), a oull was a an
Let me see
On Tue, Sep 2, 2014 at 2:49 PM, David Given wrote:
> 1) C clones M's repository.
> 2) C does some work in multiple checkins.
> 3) C points the Magic Pull Request tool at a commit. This spits out a
> bundle containing everything that's needed to add that commit (and its
> ancestors) to
Given the discussion in the other thread(s), I have been thinking about
pull requests. (I've also had a beer. You Have Been Warned.)
I rather like the pull request workflow from github and Bazaar, and it's
something that I rather miss from Fossil. However, given Fossil's
different philosophy, I th
13 matches
Mail list logo
