* Joel Bruick j...@joelface.com [20140606 06:55]:
Richard Hipp wrote:
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com
mailto:n...@cryptonector.com wrote:
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com
mailto:estifo...@gmail.com wrote:
Nico Williams n...@cryptonector.com writes:
I wouldn't, don't, and won't demand that anyone follow such a workflow for
any codebase I don't own, and possibly not for codebases I own either
(depends). I only want to be able to do it myself easily when working
on codebases where i have to or
Hey Nico --
Some thought-provoking comments. Thanks.
-bch
On 6/7/14, Gour g...@atmarama.net wrote:
Nico Williams n...@cryptonector.com writes:
I wouldn't, don't, and won't demand that anyone follow such a workflow
for
any codebase I don't own, and possibly not for codebases I own either
On Fri, Jun 6, 2014 at 10:51 PM, Nico Williams n...@cryptonector.com
wrote:
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
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.
On Fri, Jun 6, 2014 at 7:45 PM, Nico Williams n...@cryptonector.com wrote:
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
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 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,
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 a bundle that will be pushed together. A
On Wednesday, June 4, 2014, Alysson Gonçalves de Azevedo
agalys...@gmail.com javascript:_e(%7B%7D,'cvml','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
On Wed, Jun 4, 2014 at 11:08 PM, 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 do
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 encouraged to be used...
my prev comment was for the case where
On Thu, Jun 5, 2014 at 10:36 AM, B Harder brad.har...@gmail.com 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_
Using stash and doing update then commits to appropriate branches along
mostly addresses the need to split out changes from a single editing
session. The one thing it cannot do is easily accommodate a mix of changes
in a single file. That said I think I disagree that this is really needed.
In git
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com 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:
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote:
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com 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
On Thu, Jun 5, 2014 at 7:58 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote:
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote:
foo.txt has changes A, B, C and D.
After each change the developer had the
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 you have a change that
doesn't have any dependeces, you should commit that
On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo
agalys...@gmail.com 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
Richard Hipp wrote:
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com
mailto:n...@cryptonector.com wrote:
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com
mailto:estifo...@gmail.com wrote:
foo.txt has changes A, B, C and D.
After each
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com
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
the
On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com
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 choose what files to commit.
My view is that the Git staging area (I
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com
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 choose
Thus said Richard Hipp on Wed, 04 Jun 2014 14:34:31 -0400:
It clearly would not work for me.
As as an amateur user of Git, Git wasn't working for me---perhaps this
is simply due to misunderstanding ``core'' features of Git. At any rate,
thanks to Git I discovered Fossil and have been pleased
On 6/4/2014 10:50, Richard Hipp wrote:
The staging area complicates the interface.
Perhaps you will add some of this to the Fossil vs Git wiki page.
(Section 3.4?)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
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 do that, I just open GUI, check the lines of the files that i want to
commit.
(Just like this
I've heard git allows this, and occasionally wished for it.
As it stands currently, it's not possible with fossil. There is a degree of
freedom in this regard using the fossil stash, though, which can be used
with some file jigging to separate two (or more?) logical ideas that one
wants committed
26 matches
Mail list logo
