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
On Tue, 2 Sep 2014 19:47:14 -0400
Richard Hipp d...@sqlite.org 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
On Wed, Sep 3, 2014 at 9:49 AM, Gour g...@atmarama.net 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
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
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
On Wed, Sep 3, 2014 at 10:39 AM, Andy Bradford amb-fos...@bradfords.org
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
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
On Tue, Sep 2, 2014 at 6:47 PM, Richard Hipp d...@sqlite.org 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
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
Let me see
On Tue, Sep 2, 2014 at 2:49 PM, David Given d...@cowlark.com 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
On Tue, Sep 2, 2014 at 5:49 PM, David Given d...@cowlark.com 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
On Tue, Sep 2, 2014 at 3:36 PM, Ron W ronw.m...@gmail.com 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)
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 since
13 matches
Mail list logo
